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ENTERASYS NETWORKS, ENTERASYS XSR and any logos associated therewith, are trademarks or registered 
trademarks of Enterasys Networks, Inc. in the United States and other coutries. All other product names mentioned in 
this manual may be trademarks or registered trademarks of their respective owners. 

XSR Documentation URL: http://www.enterasvs.com/support/manuals 

Federal Communications Commission (FCC) Notice 

The XSR complies with Title 47, Part 15, Class A of FCC rules. Operation is subject to the following two conditions: 

• This device may not cause harmful interference. 

• This device must accept any interference received, including interference that may cause undesired operation. 

NOTE: The XSR has been tested and found to comply with the limits for a class A digital device, pursuant to Part 15 of 
the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the XSR 
is operated in a commercial environment. The XSR uses, generates, and can radiate radio frequency energy and if 
not installed in accordance with the operator's manual, may cause harmful interference to radio communications. 
Operation of the XSR in a residential area is likely to cause interference in which case you will be required to correct 
the interference at your own expense. 

WARNING: Modifications or changes made to the XSR, and not approved by Enterasys Networks may void the 
authority granted by the FCC or other such agency to operate the XSR. 

The XSR complies with Part 68 of the FCC rules and the requirements adopted by the Administrative Council for 
Terminal Attachments (ACTA). A label on the circuit board of the Network Interface Module contains, among other 
information, a product identifier in the format listed in the following table. If requested, this number must be provided to 
the telephone company. 
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Product 


Product Identifier 


NIM-T1/E1-XX, NIM-CT1 EI/PRI-xx 


US: 5N5DENANET1 


NIM-BRI-U-xx 


US: 5N5DENANEBU 



A plug and jack used to connect the XSR to the premises wiring and telephone network must comply with the 
applicable FCC Part 68 rules and requirements adopted by ACTA. Refer to the following table and installation 

instructions for details. 



Product 


Jack Used 


NIM-T1/E1-XX, NIM-CT1 EI/PRI-xx 


RJ48C 


NIM-BRI-U-xx 


RJ49C 



Codes applicable to this XSR: 



Product 


Facilities Interface Code (FIC) 


Service Order Code (SOC) 


NIM-T1/E1-xx, NIM-CT1 EI/PRI-xx 


04DU9.BN, 04DU9.DN, 
04DU9.1KN, 04DU9.1SN 


6.0N 


NIM-BRI-U-xx 


02IS5 


6.0N 



If the XSR harms the telephone network, the telephone company will notify you in advance that it may need to 
temporarily discontinue service. But if advance notice is not practical, the telephone company will notify you as soon 
as possible. Also, you will be advised of your right to file a complaint with the FCC if you believe it is necessary. 

The telephone company may make changes in its facilities, equipment, operations, or procedures that could affect the 
operation of the XSR. If this happens, the telephone company will provide advance notice for you to make necessary 
modifications and maintain uninterrupted service. 

If you experience trouble with the XSR, for repair or warranty information, please contact Enterasys Networks, Inc., at 
978 684-1000. If the XSR is causing harm to the telephone network, the telephone company may request that you 
disconnect the XSR until the problem is solved. The XSR is not intended to be repaired by the customer. 



Independent Communications Authority of South Africa 

The XSR complies with the terms of the provisions of section 54(1) of the Telecommunications Act (Act 103 of 1996) 
and the Telecommunications Regulation prescribed under the Post Office Act (Act 44 of 1958). 




SS/366.01 
APPROVED 




TE-2002/190 
APPROVED 




TE-2002/195 
APPROVED 
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Industry Canada Notices 



This digital apparatus does not exceed the class A limits for radio noise emissions from digital apparatus set out in the 
Radio Interference Regulations of the Canadian Department of Communications. 

Le present appareil numerique n'emet pas de bruits radioelectriques depassant les limites applicables aux appareils 
numeriques de la class A prescrites dans le Reglement sur le brouillage radioelectrique edicte par le ministere des 
Communications du Canada. 

EQUIPMENT ATTACHMENTS LIMITATIONS 

"NOTICE: The Industry Canada label identifies certified equipment. This certification means that the XSR meets 
telecommunications network protective, operational and safety requirements as prescribed in the appropriate Terminal 
Equipment Technical Requirements document(s). The department does not guarantee the XSR will operate to your 
satisfaction. 

Before installing the XSR, you should ensure that it is permissible to be connected to the facilities of the local 
telecommunications company. The XSR must also be installed using an acceptable method of connection. You should 
be aware that compliance with the above conditions may not prevent degradation of service in some situations. 

Repairs to certified equipment should be coordinated by a representative designated by the supplier. Any repairs or 
alterations made by you to the XSR, or equipment malfunctions, may give the telecommunications company cause to 
request you to disconnect the XSR. 

You should ensure for your own protection that the electrical ground connections of the power utility, telephone lines 
and internal metallic water pipe system, if present, are connected together. This precaution may be particularly 
important in rural areas. Caution: You should not attempt to make such connections themselves, but should contact 
the appropriate electric inspection authority, or electrician, as appropriate." 

"NOTICE: The Ringer Equivalence Number (REN) assigned to each terminal device provides an indication of the 
maximum number of terminals allowed to be connected to a telephone interface. The termination on an interface may 
consist of any combination of devices subject only to the requirement that the sum of the ringer equivalence Numbers 
of all the devices does not exceed 5." 

Regulatory Compliance Information 

Hereby, Enterasys Networks, Inc. declares that this XSR-1805 is compliant with essential requirements and other 
relevant provisions of Directive 1999/5/EC. 

Product Safety 

The XSR complies with the following: UL 1950, CSA c22.2 No.950, 73/23/EEC, EN 60950, and IEC 950. 

Use the XSR with the Advanced Power Solutions (APS61ES-30) power supply included with the branch router. 
Enterasys Networks strongly recommends that you use only the proper type of power supply cord set for the XSR. It 
should be a detachable type, UL listed/CSA certified, type SJ or SJT, rated 250 V minimum, 7 amp with grounding- 
type attachment plug. Maximum length is 15 feet (4.5 meters). The cord set should have the appropriate safety 
approval for the country in which the XSR will be installed. 

Class A ITE Notice 

WARNING: This is a class A product. In a domestic environment this product may cause radio interference in which 
case you may be required to take adequate measures. 
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VCCI Notice 



This is a class A product based on the standard of the Voluntary Control Council for Interference by Information 
Technology Equipment (VCCI) V-3. If the XSR is used in a domestic environment, radio disturbance may arise. When 
such trouble occurs, you may be required to take corrective actions. 
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VPN Consortium Interoperability 



The VPN Consortium's (VPNC) testing program is an important source for certification of conformance to IPSec 
standards. With rigorous interoperability testing, the VPNC logo program provides IPSec users even more assurance 
that the XSR will interoperate in typical business environments. VPNC is the only major IPSec testing organization 
that shows both proof of interoperability as well as the steps taken so that you can reproduce the tests. 
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BSMI (EMC) Statement - Taiwan 

This is a Class A product. In a domestic environment it may cause radio interference in which case you may be 
required to take adequate measures. 



Electromagnetic Compatibility (EMC) 

This product complies with the following: FCC Part 15 Class A; CSA C108.8, 89/336/EEC, EN 55022, EN 61000-3-2; 
EN 61000-3-3; EN 55024; AS/NZS 3548, and VCCI V-3 
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Australian Telecom 



AN 826 

WARNING: Do not install phone line connections during an electrical storm. 

WARNING: Do not connect phone line until the interface has been configured through local management. The service 
provider may shut off service if an un-configured interface is connected to the phone lines. 

WARNING: The NIM-BRI-ST cannot be connected directly to outside lines. An approved channel service unit (CSU) 
must be used for connection to the ISDN network. In some areas this CSU is supplied by the network provider and in 
others it must be supplied by you. Contact your service provider for details. 

Enterasys Networks, Inc. 
PROGRAM LICENSE AGREEMENT 

BEFORE OPENING OR UTILIZING THE ENCLOSED PRODUCT, 
CAREFULLY READ THIS LICENSE AGREEMENT. 

This document is an agreement ("Agreement") between the end user ("You") and Enterasys Networks, Inc. on behalf 
of itself and its Affiliates (as hereinafter defined) ("Enterasys") that sets forth Your rights and obligations with respect to 
the Enterasys software program (including any accompanying documentation, hardware or media) ("Program") in the 
package and prevails over any additional, conflicting or inconsistent terms and conditions appearing on any purchase 
order or other document submitted by You. "Affiliate" means any person, partnership, corporation, limited liability 
company, or other form of enterprise that directly or indirectly through one or more intermediaries, controls, or is 
controlled by, or is under common control with the party specified. This Agreement constitutes the entire 
understanding between the parties, and supersedes all prior discussions, representations, understandings or 
agreements, whether oral or in writing, between the parties with respect to the subject matter of this Agreement. The 
Program may be contained in firmware, chips or other media. 

BY INSTALLING OR OTHERWISE USING THE PROGRAM, YOU REPRESENT THAT YOU ARE AUTHORIZED TO 
ACCEPT THESE TERMS ON BEHALF OF THE END USER (IF THE END USER IS AN ENTITY ON WHOSE 
BEHALF YOU ARE AUTHORIZED TO ACT, "YOU" AND "YOUR" SHALL BE DEEMED TO REFER TO SUCH 
ENTITY) AND THAT YOU AGREE THAT YOU ARE BOUND BY THE TERMS OF THIS AGREEMENT, WHICH 
INCLUDES, AMONG OTHER PROVISIONS, THE LICENSE, THE DISCLAIMER OF WARRANTY AND THE 
LIMITATION OF LIABILITY. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT OR ARE NOT 
AUTHORIZED TO ENTER INTO THIS AGREEMENT, ENTERASYS IS UNWILLING TO LICENSE THE PROGRAM 
TO YOU AND YOU AGREE TO RETURN THE UNOPENED PRODUCT TO ENTERASYS OR YOUR DEALER, IF 
ANY, WITHIN TEN (10) DAYS FOLLOWING THE DATE OF RECEIPT FOR A FULL REFUND. 

IF YOU HAVE ANY QUESTIONS ABOUT THIS AGREEMENT, CONTACT ENTERASYS NETWORKS, LEGAL 
DEPARTMENT AT (978) 684-1000. 

You and Enterasys agree as follows: 

1 ) LICENSE. You have the non-exclusive and non-transferable right to use only the one (1 ) copy of the 
Program provided in this package subject to the terms and conditions of this Agreement. 

2) RESTRICTIONS. Except as otherwise authorized in writing by Enterasys, You may not, nor may You permit 
any third party to: 
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(i) Reverse engineer, decompile, disassemble or modify the Program, in whole or in part, including for 
reasons of error correction or interoperability, except to the extent expressly permitted by applicable law and 
to the extent the parties shall not be permitted by that applicable law, such rights are expressly excluded. 
Information necessary to achieve interoperability or correct errors is available from Enterasys upon request 
and upon payment of Enterasys' applicable fee. 

(ii) Incorporate the Program, in whole or in part, in any other product or create derivative works based on the 
Program, in whole or in part. 

(iii) Publish, disclose, copy, reproduce or transmit the Program, in whole or in part. 

(iv) Assign, sell, license, sublicense, rent, lease, encumber by way of security interest, pledge or otherwise 
transfer the Program, in whole or in part, except for a sale or other transfer of the hardware in which the 
Program is embedded. 

(v) Remove any copyright, trademark, proprietary rights, disclaimer or warning notice included on or 
embedded in any part of the Program. 

3) APPLICABLE LAW. This Agreement shall be interpreted and governed under the laws and in the state and 
federal courts of the Commonwealth of Massachusetts without regard to its conflicts of laws provisions. You 
accept the personal jurisdiction and venue of the Commonwealth of Massachusetts courts. None of the 1980 
United Nations Convention on Contracts for the International Sale of Goods, the United Nations Convention on 
the Limitation Period in the International Sale of Goods, and the Uniform Computer Information Transactions Act 
shall apply to this Agreement. 

4) EXPORT RESTRICTIONS. You understand that Enterasys and its Affiliates are subject to regulation by 
agencies of the U.S. Government, including the U.S. Department of Commerce, which prohibit export or diversion 
of certain technical products to certain countries, unless a license to export the Program is obtained from the U.S. 
Government or an exception from obtaining such license may be relied upon by the exporting party. 

If the Program is exported from the United States pursuant to the License Exception CIV under the U.S. Export 
Administration Regulations, You agree that You are a civil end user of the Program and agree that You will use the 
Program for civil end uses only and not for military purposes. 

If the Program is exported from the United States pursuant to the License Exception TSR under the U.S. Export 
Administration Regulations, in addition to the restriction on transfer set forth in Sections 1 or 2 of this Agreement, 
You agree not to (i) reexport or release the Program, the source code for the Program or technology to a national 
of a country in Country Groups D:1 or E:2 (Albania, Armenia, Azerbaijan, Belarus, Bulgaria, Cambodia, Cuba, 
Estonia, Georgia, Iraq, Kazakhstan, Kyrgyzstan, Laos, Latvia, Libya, Lithuania, Moldova, North Korea, the 
People's Republic of China, Romania, Russia, Rwanda, Tajikistan, Turkmenistan, Ukraine, Uzbekistan, Vietnam, 
or such other countries as may be designated by the United States Government), (ii) export to Country Groups 
D:1 or E:2 (as defined herein) the direct product of the Program or the technology, if such foreign produced direct 
product is subject to national security controls as identified on the U.S. Commerce Control List, or (iii) if the direct 
product of the technology is a complete plant o r any major component of a plant, export to Country Groups D:1 or 
E:2 the direct product of the plant or a major component thereof, if such foreign produced direct product is subject 
to national security controls as identified on the U.S. Commerce Control List or is subject to State Department 
controls under the U.S. Munitions List. 

5) UNITED STATES GOVERNMENT RESTRICTED RIGHTS. The enclosed Program (i) was developed solely 
at private expense; (ii) contains "restricted computer software" submitted with restricted rights in accordance with 
section 52.227-19 (a) through (d) of the Commercial Computer Software- Restricted Rights Clause and its 
successors, and (iii) in all respects is proprietary data belonging to Enterasys and/or its suppliers. For Department 
of Defense units, the Program is considered commercial computer software in accordance with DFARS section 
227.7202-3 and its successors, and use, duplication, or disclosure by the Government is subject to restrictions set 
forth herein. 
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6) DISCLAIMER OF WARRANTY. EXCEPT FOR THOSE WARRANTIES EXPRESSLY PROVIDED TO YOU 
IN WRITING BY ENTERASYS, ENTERASYS DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, 
SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT 
WITH RESPECT TO THE PROGRAM. IF IMPLIED WARRANTIES MAY NOT BE DISCLAIMED BY 
APPLICABLE LAW, THEN ANY IMPLIED WARRANTIES ARE LIMITED IN DURATION TO THIRTY (30) DAYS 
AFTER DELIVERY OF THE PROGRAM TO YOU. 

7) LIMITATION OF LIABILITY. IN NO EVENT SHALL ENTERASYS OR ITS SUPPLIERS BE LIABLE FOR 
ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS, 
PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, SPECIAL, INCIDENTAL, 
CONSEQUENTIAL, OR RELIANCE DAMAGES, OR OTHER LOSS) ARISING OUT OF THE USE OR INABILITY 
TO USE THE PROGRAM, EVEN IF ENTERASYS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGES. THIS FOREGOING LIMITATION SHALL APPLY REGARDLESS OF THE CAUSE OF ACTION 
UNDER WHICH DAMAGES ARE SOUGHT. 

THE CUMULATIVE LIABILITY OF ENTERASYS TO YOU FOR ALL CLAIMS RELATING TO THE PROGRAM, IN 
CONTRACT, TORT OR OTHERWISE, SHALL NOT EXCEED THE TOTAL AMOUNT OF FEES PAID TO 
ENTERASYS BY YOU FOR THE RIGHTS GRANTED HEREIN. 

8) AUDIT RIGHTS. You hereby acknowledge that the intellectual property rights associated with the Program are 
of critical value to Enterasys and, accordingly, You hereby agree to maintain complete books, records and accounts 
showing (i) license fees due and paid, and (ii) the use, copying and deployment of the Program. You also grant to 
Enterasys and its authorized representatives, upon reasonable notice, the right to audit and examine during Yourr 
normal business hours, Yourr books, records, accounts and hardware devices upon which the Program may be 
deployed to verify compliance with this Agreement, including the verification of the license fees due and paid 
Enterasys and the use, copying and deployment of the Program. Enterasys' right of examination shall be exercised 
reasonably, in good faith and in a manner calculated to not unreasonably interfere with Yourr business. In the event 
such audit discovers non-compliance with this Agreement, including copies of the Program made, used or deployed in 
breach of this Agreement, You shall promptly pay to Enterasys the appropriate license fees. Enterasys reserves the 
right, to be exercised in its sole discretion and without prior notice, to terminate this license, effective immediately, for 
failure to comply with this Agreement. Upon any such termination, You shall immediately cease all use of the Program 
and shall return to Enterasys the Program and all copies of the Program. 

9) OWNERSHIP. This is a license agreement and not an agreement for sale. You acknowledge and agree that 
the Program constitutes trade secrets and/or copyrighted material of Enterasys and/or its suppliers. You agree to 
implement reasonable security measures to protect such trade secrets and copyrighted material. All right, title and 
interest in and to the Program shall remain with Enterasys and/or its suppliers. All rights not specifically granted to 
You shall be reserved to Enterasys. 

1 0) ENFORCEMENT. You acknowledge and agree that any breach of Sections 2, 4, or 9 of this Agreement by 
You may cause Enterasys irreparable damage for which recovery of money damages would be inadequate, and 
that Enterasys may be entitled to seek timely injunctive relief to protect Enterasys' rights under this Agreement in 
addition to any and all remedies available at law. 

11) ASSIGNMENT. You may not assign, transfer or sublicense this Agreement or any of Your rights or 
obligations under this Agreement, except that You may assign this Agreement to any person or entity which 
acquires substantially all of Your stock or assets. Enterasys may assign this Agreement in its sole discretion. This 
Agreement shall be binding upon and inure to the benefit of the parties, their legal representatives, permitted 
transferees, successors and assigns as permitted by this Agreement. Any attempted assignment, transfer or 
sublicense in violation of the terms of this Agreement shall be void and a breach of this Agreement. 
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12) WAIVER. A waiver by Enterasys of a breach of any of the terms and conditions of this Agreement must be 
in writing and will not be construed as a waiver of any subsequent breach of such term or condition. Enterasys' 
failure to enforce a term upon Your breach of such term shall not be construed as a waiver of Your breach or 
prevent enforcement on any other occasion. 

13) SEVERABILITY. In the event any provision of this Agreement is found to be invalid, illegal or 
unenforceable, the validity, legality and enforceability of any of the remaining provisions shall not in any way be 
affected or impaired thereby, and that provision shall be reformed, construed and enforced to the maximum 
extent permissible. Any such invalidity, illegality or unenforceability in any jurisdiction shall not invalidate or render 
illegal or unenforceable such provision in any other jurisdiction. 

14) TERMINATION. Enterasys may terminate this Agreement immediately upon Your breach of any of the terms 
and conditions of this Agreement. Upon any such termination, You shall immediately cease all use of the Program 
and shall return to Enterasys the Program and all copies of the Program. 

DECLARATION OF CONFORMITY 

Application of Council Directive(s) : 89/336/EEC 

73/23/EEC 

Manufacturer's Name: Enterasys Networks, Inc. 

Manufacturer's Address: 50 Minuteman Road 
Andover, MA 01810 
USA 

European Representative Address: Enterasys Networks Ltd. 

Nexus House, Newbury Business Park 
London Road, Newbury 
Berkshire RG14 2PZ, England 

Conformance to Directive(s)/Product Standards: EC Directive 89/336/EEC 

EC Directive 73/23/EEC 
EN 55022 
EN 55024 
EN 60950 
EN 60825 

Equipment Type/Environment: Networking Equipment, for use in a Commercial 

or Light Industrial Environment. 

Enterasys Networks, Inc. declares that the XSR packaged with this notice conforms to the above directives. 
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About This Guide 



This guide provides a general overview of the XSR hardware and software 
features. It describes how to configure and maintain the router. Refer to the 
XSR CLI Reference Guide and the XSR Getting Started Guide for information not 
contained in this document. 

This guide is written for administrators who want to configure the XSR or 
experienced users who are knowledgeable of basic networking principles. 

Contents of the Guide 

Information in this guide is arranged as follows: 

□ Chapter 1, Overview, introduces key features of the XSR. 

□ Chapter 2, Managing the XSR, describes the three methods of 
managing the router along with the control commands and tools 
available to accomplish that task. 

□ Chapter 3, Managing LAN/WAN Interfaces, describes system 
FastEthernet/ GigabitEthernet and High Speed Serial features, how to 
configure them, and MIB-II statistics collected for LAN interfaces. 

□ Chapter 4, Configuring Tl/El Interfaces, outlines XSR controller 
features, and how to configure and troubleshoot them. 

□ Chapter 5, Configuring IP, outlines a host of XSR IP protocol suite 
features and routing their associated configuration commands. 

□ Chapter 6, Configuring PPP, details XSR support for the PPP protocol 
and how to configure it. 

□ Chapter 7, Configuring Frame Relay, details how to set up Frame Relay 
networks on the XSR. 

□ Chapter 8, Configuring Dial Services and Back Up, details background 
information about Dial Services and Dial Backup across a PSTN, and 
the commands to configure these features. 

□ Chapter 9, Configuring ISDN, outlines how to set up the Integrated 
Services Digital Network protocol on the XSR for BRI, PRI and leased 
line applications. 
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About This Guide 



□ Chapter 10, Configuring Quality of Service, describes XSR support for 
QoS, including Random Early Detection, tail-drop, DSCP, IP 
precedence, traffic policing, priority and CBWFQ queuing. 

□ Chapter 11, Configuring the Virtual Private Network, outlines XSR 
support for Site-to-Site, Site-to-Central-Site, and Remote Access VPN 
applications. Other supported functionality includes RADIUS 
authentication, PKI authentication, NAT traversal, IP address 
management, and dynamic routing over VPN (remote access only). 

□ Chapter 12, Configuring DHCP, details the router's support for the 
Dynamic Host Configuration Protocol including dynamic and 
manual IP address allocation. 

□ Chapter 13, Configuring Security, describes methods to protect the 
router against hacker attacks and how to configure them. 

□ Appendix A, Alarms and Events, lists the high, medium and low 
severity alarms and events captured by the XSR. 
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Conventions Used in This Guide 



Conventions Used in This Guide 

The following conventions are used in this guide: 

Notes supply additional helpful information, 
provide a cross-reference to the source of more 
information, or emphasize issues you should 
consider when performing an action. 

Cautions contain directions that can prevent you 
from damaging the product or losing data. 

Warnings provide directions that you must 
follow to avoid harming yourself. 

Bold Text in boldface indicates values you type using 

the keyboard or select using the mouse (for 
example, a:\setup). Default settings may also 
appear in bold. 

Italics Text in italics indicates a variable, important new 

term, or the title of a manual. 

SMALL CAPS Small caps specify the keys to press on the 

keyboard; a plus sign (+) between keys indicates 
that you must press the keys simultaneously (for 
example, CTRL+ALT+DEL). 

Courier font Text in this font denotes a file name or directory. 

^ Points to text describing CLI command. 

FastEthernet FastEthernet and GigabitEthernet references are 

generally interchangeable throughout this guide. 
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About This Guide 



Getting Help 



For additional support related to the XSR, contact Enterasys Networks using 
one of the following methods: 



World Wide Web 


httD://www.enterasvs.com 


Phone 


/r\~70\ r*o a a r\r\r\ 

(978) 684-1000 

1-800-872-8440 (toll-free in U.S. and Canada) 

For the Enterasys Networks Support toll-free number in your country: 

http://www.enterasYS.com/support/qtac-all.html 


Internet mail 


support@enterasys.com 


FTP 


ftp://ftp.enterasys.com 


Login 


anonymous 


Password 


your email address 


Acquire the latest image 
and Release Notes 


http://www.enterasYS.com/download 


Additional documentation 


http://www.enterasYS.com/support/manuals 


Forward comments or 
suggestions 


techwriting@enterasys.com 



Before contacting Enterasys Networks for technical support, have the 
following information ready: 

□ Your Enterasys Networks service contract number 

□ A description of the failure 

□ A description of any action(s) already taken to resolve the problem 
(e.g., rebooting the unit, reconfiguring modules, etc.) 

□ The serial and revision numbers of all relevant Enterasys Networks 
products in the network 

□ A description of your network environment (layout, cable type, etc.) 

□ Network load and frame size at the time of the problem 

□ The XSR's history (i.e., have you returned the device before, is this a 
recurring problem, etc.) 

□ Any previous Return Material Authorization (RMA) numbers 
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Overview 



This chapter briefly describes the functionality of the XSR. Refer to the 
following chapters in this manual for details on how to configure this 
functionality and the XSR CLI Reference Guide for a description of associated 
CLI commands and examples. 

The following functionality is supported on the XSR: 

□ System Management - The XSR's resources can be managed via four 
methods: the Command Line Interface (CLI) for full configuration, 
performance and fault management; the Simple Network 
Management Protocol (SNMP) including SNMP vl/v2c/v3 agent, 
for remote monitoring; the NetSight Atlas Router Services Manager 
application for firewall and ACL configuration; and the Web to 
gather version information. These tools control the XSR's many 
hardware and software facilities. Also supported: SSH v2 server, full 
configuration backup and restore, login banner, and a host of 
proprietary and standard MIBs including Syslog, Configuration 
Management, Configuration Change, TimedReset, Entity, Chassis 
and Protocol MIBs (OSPF, RIP, Frame Relay, and PPP). 

□ Ethernet Interfaces - The XSR 1800 Series' two 10/100 Base-T 
FastEthernet interfaces and XSR 3000 Series' three 10/100/1000 
BaseT GigabitEthernet interfaces handle the router's LAN traffic 
stream, with support for alarms and events, diagnostics, packet 
filtering and statistics gathering, and Ethernet backup. 

□ Tl/El Interfaces - The XSR's Tl/El subsystem on a single NIM-based 
1/ O card handles the router's WAN traffic with support for alarm 
detection and signaling, diagnostics, line encoding, and a host of 
other functionality. 
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□ Serial Interface - The XSR's NIM serial interface typically supports 
protocols such as PPR The serial interface provides both 
asynchronous and synchronous protocol support. 

□ PPP (WAN) -The Point-to-Point Protocol (PPP) provides a standard 
method for transporting multi-protocol datagrams over point-to- 
point links. PPP defines procedures for the assignment and 
management of network addresses, asynchronous and synchronous 
encapsulation, link configuration, link quality testing, network 
protocol multiplexing, error detection, and option negotiation for 
such capabilities as network-layer address negotiation and data- 
compression negotiation. Also supported: PPPoE Client and sub- 
interface monitoring, and Multilink PPP protocols as well as Dial on 
Demand (DoD) and Bandwidth on Demand (BoD). 

□ IP Protocol - IP supports interconnected systems of packet-switched 
computer communication networks. It uses a 32-bit addressing 
scheme where an IP address is represented by four fields, each 
containing 8-bit numbers. Also supported: secondary IP addressing. 

□ DHCP Server - The XSR supports DHCP Server on the trusted LAN to 
provide IP addresses to computers on a customer's private LAN 
segment. 

□ Network Address Translation (NAT) and Port Address Translation 
(PAT); Automatic NAT transversal extension enables VPN traffic to 
connect through ISP or service provider network. 

□ IP Routing - The XSR supports RIP and OSPF dynamic routing, a vital 
function of the IP protocol. Stored in a routing table, routing 
information is used by the XSR to determine the route for each packet 
passing through the router. VRRP is also supported for default router 
redundancy and load balancing. 

□ Frame Relay - The XSR provides this fast-packet switching method for 
wide-area networking. Acting as a DTE, the router encapsulates data 
in a frame and transmits that data while serving as a source device. 
When it is a destination device, it receives frames and de- 
encapsulates them. The XSR's implementation of Frame Relay 
employs the User Network Interface (UNI) for PVC (DLCI) 
connections with Committed Information Rate (CIR) traffic shaping 
and BECN congestion control. 
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□ Quality of Service - The XSR provides traffic classification using IP 
Precedence and DSCP bits, bandwidth control via metered, policed 
and prioritized traffic queues, and queue management utilizing Drop 
Tail and Random Early Detection (RED). 

□ Virtual Private Network - The XSR supports VPN tunnels using L2TP, 
PPP or IPSec protected by DES, 3DES, RC4, MD5 or SHA-1 
encryption. VPN tunnels are authenticated /authorized for 
credentials using pre-shared keys or Public Key Infrastructure (PKI). 
Also supported: DF Bit override, OSPF over VPN, and interaction 
between firewall/NAT/VPN. 

□ Security - In its firewall feature set, the XSR provides stateful firewall 
protection against a variety of Denial of Service attacks, FTP and 
H.323 ALG support, application command filtering for FTP, SMTP 
and HTTP, firewall logging and authentication, and supports Access 
Control Lists to manage network access. Also supported: AAA for 
firewall, Console /Telnet and SSHv2 users. 

□ Dialer Interface - Dial Services are a cost-saving alternative to the 
leased line connection between two peers and they can be 
implemented for different types of media for both inbound and 
outbound connections. 

□ Dial Backup - The dialed backup feature provides a backup link over a 
dial line. The backup link is brought up when a failure occurs in a 
primary link, and it is brought down when the primary link is 
restored. This feature is supported for PPPoE to enable cable backup 
over FastEthernet/ GigabitEthernet sub-interfaces. 

□ ISDN - The XSR's BRI and PRI switched and leased lines set up and 
tear down calls, usually under the control of the Dialer. The XSR's 
ISDN services BRI and PRI lines with a 1, 2 or 4 port Channelized 
NIM card for PRI lines, 1 or 2 port BRI-S/T NIM card, or 1 or 2 port 
BRI U NIM card. Also supported: bandwidth optimization through 
DoD, BoD and BAP, security through caller ID, call monitoring, and 
ISDN callback. 
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Managing the XSR 



The XSR can be managed via three interfaces with varying levels of control: 
the Command Line Interface (CLI) for full configuration, performance and 
fault management; the Simple Network Management Protocol (SNMP) for 
remote monitoring and firmware upgrades, and the Web for gathering 
version information. 

Utilizing the Command Line Interface 

The Command Line Interface (CLI) is a widely used tool to access and control 
configurable parameters of the XSR. You can access the CLI three ways: 

□ Directly connect to the Console port via an asynchronous terminal 

□ Over the network using Telnet or SSH via a LAN or WAN interface 

Connecting via the Console Port 

For ease of use when first setting up the XSR, you can directly connect the 
Console port to an asynchronous terminal (via Microsoft's HyperTerminal or 
other program) with the following values: 8 data bits, no parity, 9600 bps, 1 
stop bit, flow control - none. Because the Console port is wired as a DCE with 
a DB-9 connector, a standard DB-9 straight-through null modem cable is 
needed to attach a standard PC COM port to the Console port. 

Although a login (admin) is required to make this connection, for additional 
security you can later delete the admin user as well as disable Telnet sessions 
through the Console. 

Optionally, you can set up the Console port as a WAN interface for dial backup 
purposes (refer to the following Caution). For directions, refer to the XSR 
Getting Started Guide. 
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rp\ CAUTION 

When you enable the Console port as a WAN port, you can no longer 
directly connect to it because is in data communication mode. Your only 
access to the CLI will be to Telnet/SSH to an IP address of a configured 
port. Also, if star tup -conf ig does not set up any of the ports properly 
and sets up the console port as a serial port, you will no longer be able to 
login and will have to press the Default button to erase the configuration. 



Terminal Commands 

If you want to display identification information about the current terminal 
connection, issue the show whoami command. Refer to the XSR Getting Started 
Guide for more information on commands. 



Connecting via Telnet 

Once the XSR is properly configured with a valid IP address, you can 
remotely connect to the CLI via Telnet using the default user admin with no 
password. Later, you can create users with the username command. 



NOTE 



The XSR supports a maximum of 25 users. 



Although up to five concurrent Telnet/SSH and one Console sessions are 
supported, if more than one session is running simultaneously (including the 
Console session), only one session permits configuration changes. Any other 
session could only view configuration settings. This prohibition applies to all 
commands that make changes to the configuration and is limited to Global 
mode. For example, if a user is in Global mode and another user tries to enter 
Global mode, the second user will get the following error message: 

XSR#conf ig 

Configuration is currently locked by user admin. Please try later. 

Also, in order to ensure that an administrator can always login to the router, 
one of the five permitted Telnet or SSH sessions is always reserved for the 
administrator. 
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That is, if the first four sessions are regular users, the fifth session will allow 
only the administrator to login. But if one of the first four is logged in as 
administrator, then the fifth session can be any user. You can also Telnet from 
the XSR to a server by using the telnet ip_address command. It is a useful 
utility for diagnostics. Be aware that the router will try to make a Telnet 
connection for 70 seconds. 

Connecting via SSH 

Secure Shell (SSH v2) encrypts the link to the XSR so it is a more secure 
alternative to Telnet for remote connections. To activate SSH, invoke the 
following commands: 

□ Create a host key pair with crypto dsa generate 

□ Add an user with password and privilege level with aaa user, 
password and privilege 15 

□ Enable SSH access wth policy ssh 

□ Enable local authentication with aaa client ssh 

□ Load an SSH client application on your PC to connect with the XSR 

□ Optionally, you can disable Telnet with ip telnet server disable 
for higher security 

□ Optionally, if you are enabling the firewall feature set you can 
configure an Access Control List (ACL) to allow a single host SSH 
access to the XSR by entering these commands: 

XSR (conf ig) #access - list 100 permit tcp host 192.168.1.10 eq 22 

XSR (conf ig) #access-list 100 deny tcp any host 192.168.1.10 eq 22 

XSR (conf ig) #access-list 100 permit ip any 

XSR (conf ig) #interf ace fastethernet 1 

XSR (conf ig-if<Fl>) #ip access-group 100 in 

PuTTY and other shareware programs are compatible with the XSR's SSH 
server. 

Refer to the XSR Getting Started and CLI Reference guides for more details. 
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Accessing the Initial Prompt 

The CLI is protected by security. Before you can access EXEC mode, you must 
enter a valid password. This mode lets you test basic connectivity of the XSR 
but does not permit you to change or monitor the router's configuration. 
Access to enhanced commands is permitted only if you enter Privileged 
EXEC mode by entering enable. You can logout at any time by entering exit 
while in EXEC mode. 

Refer to Table 1 for session limits. 



Table 1 CLI Session Limits 



Parameter 


Limit 


Total number of CLI Telnet/SSH sessions permitted 


5 


SSH sessions permitted with 32 MBytes of memory 


1 


Console sessions permitted 


1 


Number of Telnet sessions reserved for administrators 


1 


Terminal auto-logout timeout value (configurable) 


1800 seconds 



The show limits command defines all system software and memory limits 
as well as values and memory utilized. Refer to the XSR CLI Reference Guide 
for more details. 



Managing the Session 

A first-time CLI session is set up with default attributes; e.g., the session is set 
to time out after 1800 seconds of idle time. You can reconfigure session values 
such as create users, passwords, and login banners, and set Telnet and Web 
access. Refer to the XSR CLI Reference Guide for details about these commands. 

CLI Editing Rules 

To use the CLI efficiently, be aware of the following rules: 

□ Case-sensitivity: CLI commands are not case-sensitive. For example, 
you can enter either show version or show version to display the 
XSR's software revision. But, some parameters may be case sensitive. 
For example, entering snmp- server community public is different 
from snmp- server community Public 
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□ Command Abbreviation: You can abbreviate commands and keywords 
to the minimum number of characters that define a unique 
abbreviation. For example, you can abbreviate the hostname 
command to hostn (but you cannot abbreviate to hos because other 
commands also start with the letters hos). 

□ Output Display: By default, output data are displayed one page at a 
time if the data occupies more than one page. In this case, you can use 
the spacebar to scroll down to the next page or press enter to scroll 
down one line at a time. The default page size is 132 characters wide, 
23 rows high and they are configurable in a range from 0 to 512 
characters using the terminal command. Refer to the XSR CLI 
Reference Guide for more information about the command. 

□ Command Recall: Non-help commands are stored in the command 
history list buffer up to the last 32 commands. You can recall and edit 
previous commands using shortcut keys. For example: 
ctrl+p/ctrl+n will list the previous/next command respectively 
and can be applied repeatedly. The up-arrow or down-arrow keys 
provide the same feature if your terminal supports these keys. 

□ Tab Completion: Pressing the tab key or Ctrl+i completes a command. 
In case of an ambiguous match, the word is completed up to the 
character which leads to ambiguity. For example, hostname and 
host Dos share the letters host, so tab completion completes the 
"command" ho to host. 

□ Carriage Return/Enter: Pressing the carriage return/ENTER key signals 
the end of a CLI command. 

□ Help Symbol: At any point you can enter the? character to prompt for 
a list of possible commands /parameters at a particular mode. 

□ Error: Proper error messages are displayed if the command could not 
be issued due to syntax errors or invalid values made by the user. 

Typing these characters will produce output as follows: 

XSR#showFIioLLJl 
XSR#showFIioLLJl 

% invalid input detected at ' * 1 marker 
XSR# 
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□ CLI Terminal Editing Command Keys: Refer to the following table for 
these useful shortcuts. 



Table 2 CLI Terminal Editing Commands 



Command 


Description 


Ctrl + a 


Move cursor to beginning of line 


Ctrl + b 


Move cursor back 1 character 


Ctrl + c 


Same as the CLI end command 


Ctrl + d 


Delete 1 character after cursor 


Ctrl + e 


Move cursor to end of line 


Ctrl + f 


Move cursor forward 1 character 


Ctrl + h 


Delete 1 character before cursor 


Ctrl + 1 


Tab completion 


Ctrl + k 


Delete all characters after cursor 


Ctrl + 1 


Echo current line 


Ctrl + n 


Next CLI command in history 


Ctrl + p 


Previous CLI command in history 


Ctrl + r 


Echo current line 


Ctrl + u 


Delete all characters before cursor 


Ctrl + w 


Delete 1 word before cursor 


Ctrl + x 


Delete all characters before cursor 


Ctrl + y 


Restores the most recently deleted item 


Ctrl + z 


Same as the CLI end command 


Del 


Delete a character 


Esc + b 


Move cursor back 1 word 


Esc + d 


Delete to end of word at cursor 


Esc + f 


Move cursor forward 1 word 
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Setting CLI Configuration Modes 

The CLI provides modes of operation permitting a subset of commands to be 
issued from each mode. Also, you can issue any command and acquire any 
mode if the command entered or mode acquired subscribes to the same parent. 
For example, you can issue the interface serial command at Crypto Map 
mode because both Serial Interface and Crypto Map modes subscribe to 
Global (config) mode. Table 3 describes a few primary modes of operation. 

Table 3 CLI Configuration Modes 



Mode 


Function 


Access Method 


Prompt 


User 
EXEC 


Password-protected mode: 
•Changes terminal settings 
•Performs basic tests 
•Displays system information 


Login process 


XSR> 


Privileged 
EXEC 


This mode: 

•Sets system operating values 
•Shows configuration parameters 
•Saves/copies configurations 


Enter enable in User EXEC 


XSR# 


Global 


Sets system-wide values. Save changes 
after a reboot by copying the running- 
configuration to the startup-configuration. 


Enter configure terminal 
in Privileged EXEC 


XSR (config) # 


Interface 


Modifies/assigns port parameters on a 
port-by-port basis. 


Enter interface 
interface- type <port#> 
in Global mode 


XSR (conf ig- 
if <xx>) # 


Router 


Sets RIP or OSPF parameters. 


Enter router rip/ospf in 
Global mode 


XSR (conf ig- 
router) # 



Refer to Figure 1 for a graphic example of configuration modes. 
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Login 

i 

EXEC 




Config-Router T1/E1 



Figure 1 Sample Configuration Mode Tree 

The footnotes below refer to command options cited in the illustration. 

1 if-type can be one of the following: Serial, FastEthernet, 
GigabitEthernet, BRI, loopback, Multilink, VPN, or Dialer 

2 router-parameter can be: RIP or OSPF 

3 controller can be one of the following: T1 or E1 

4 Some attributes can be set at this level without acquiring other 

modes. For example: access-list access-list-num [deny | 
permit] [parameter [parameter...] ] 

5 show commands can all be entered at EXEC, Privileged EXEC or 
Global modes. 
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User EXEC Mode 

You enter User EXEC (or simply EXEC) mode after logging in. The following 
sample commands can be entered in EXEC mode: 

□ enable 

□ ping 

Privileged EXEC Mode 

In order to make the changes to the configuration, you must enter PRIV EXEC 
mode. Some configuration parameters specified in this mode apply to 
XSR global settings such as the system clock. 

Global Configuration Mode 

In Global configuration mode you can configure many different resources 
such as ports, interfaces, and routing tables. The following levels are provided 
at the Global configuration level: 

□ Interface Level: At this level you can modify/ assign specific port 
parameters on a port-by-port basis. You can enter this level by typing 
interface interface- type <interface #> at the Global 
configuration command prompt. For example, you can enter: 

XSR (conf ig) #interf ace gigabitethernet 3 

The XSR- 1850 will return the following prompt: 

XSR(config-if<G3>) # 

□ Router level: At this level you can configure parameters associated 
with the RIP or OSPF protocols. You reach this level by typing router 
[RIP, OSPF] in Global mode. For example, enter: 

XSR (conf ig) #router rip 

The XSR- 1850 will return the following prompt: 
XSR (conf ig-router) # 

□ Several other levels are available in Global mode including AAA, 
Class-Map, Crypto, Dialer, IP, and Map-Class. Many of these modes 
have additional levels nested within them. 
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Exiting From the Current Mode 

Each of these commands exits from your mode but with different results: 

□ Exit: In each mode exit quits from the current to previous mode 

□ End: end always returns to Privileged EXEC from either Global or 
sub-configuration mode 

□ Ctrl-Z: Same as the end command 

□ Be aware that you need not always exit from a mode if your current 
and destination modes subscribe to the same parent in the mode tree. 

Mode Examples 

Consider the following examples to change configuration mode: 

XSR>enable Acquires Privileged EXEC mode 

XSR#config terminal ^ Acquires Global configuration mode 

XSR (conf ig) #interf ace fastethernet 1 ^ Acquires Interface mode 

XSR(config-if<Fl>) #ip address 192.168.2.2.255.255.255.0 

^ Sets up the IP address and subnet mask for this FastEthernet port 

XSR (conf ig-if<Fl>) #exit ^ Quits Interface mode 
XSR (conf ig) #exit ^ Quits Global mode 
XSR#disable ^ Quits Privileged EXEC mode 
XSR> i®" Returned to EXEC mode by previous command 



Observing Command Syntax and Conventions 

The CLI command syntax and conventions use the notation described below. 

Table 4 CLI Syntax 



Convention 


Description 


xyz 


Key word or mandatory parameters (bold) 


M 


[ ] Square brackets indicate an optional parameter (italic) 


[x 1 y 1 z] 


[ 1 ] Square brackets with vertical bar indicate a choice of values 


jx 1 y 1 zj 


{ 1 } Braces with vertical bar indicate a choice of a required value 
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Table 4 CLI Syntax 



Convention 


Description 


[x (ylz)] 


[{ 1 } ] Combination of square brackets with braces and vertical bars 
indicates a required choice of an optional parameter 


(conf ig-if <xx>) 


xx signifies the interface type; e.g., Fl, G3, S2/1 . 0, Dl, lo, bri, pri 
(ti/ei), vpn, etc. 



In the following example: 

show interface [dialer I f astEthernet/gigabitethernet I 
loopback I serial | bri | multilink | vpn {interface -number}] 

□ show and interface are keywords 

□ [dialer, fastEthernet, gigabitethernet, loopback, serial, bri, 
multilink, vpn and {interface -number}] are optional parameters 

Syntactically, each line begins with one or more command keywords followed 
by a list of mandatory parameters (if any) and, lastly, a list or optional 
parameters. For example the following command: 

channel -group number timeslots range [speed {56 | 64}] 

has a mandatory parameter value number, a mandatory parameter keyword 
and value pair timeslots range, an optional parameter presented as a 
keyword speed and value options of 56 or 64. 

CLI Command Limits 

CLI commands are bounded by the following: 

□ Total number of characters in a command line /help message: 299 

□ Total number of words in a command line: 127 

□ Number of command history entries recalled: 31 

□ Total number of characters in a prompt: 1023 

□ Total number of characters in system name: 31 
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Describing Ports and Interfaces 

This section describes ports and interfaces, the rules for port identification, 
and the association of port with interface. 

Technically speaking, a port is a physical connector with some physical layer 
values. XSR ports are: FastEthernet or GigabitEthernet, async and sync serial, 
and Tl/El. An interface is a data and management plane comprising the 
physical, link, and some part of the network layer. The terms are often used 
interchangeably in this manual. FastEthernet ports are provided on the 
XSR 1800 Series, and GigabitEthernet ports on the XSR 3000 Series routers. 

The XSR supports multiple access types, including FastEthernet/ GigabitEthernet 
LAN, Frame Relay and serial WAN access over Asynchronous, Synchronous, 
Tl/El, and serial lines. Async and Sync access can be over permanent or dial lines. 
Generally, Frame Relay and PPP are used for WAN access and PPPoE for WAN 
access over a LAN. Dial access is provided by ISDN BRI and PRI. 

Supported Physical Interfaces 

□ FastEthernet /GigabitEthernet for LAN port consisting of Ethernet's 
physical, Mac (Layer-2), and IP layer functionality. 

□ Serial for Sync port /line consisting of a Sync port/line's physical, 
Layer-2 (PPP) and IP layer functionality. 

□ Serial for Async port /line consisting of an Async port /line's physical, 
Layer-2 (PPP), and IP layer functionality. 

□ Serial for Tl/El channel group consisting of its physical, Layer-2 (PPP 
or Frame Relay), and IP layer functionality. 

Supported Virtual Interfaces 

□ Interface dialer includes physical interfaces supporting dial 
connectivity from the dial port /line's physical layer functionality 
including dialing, Layer-2 (PPP), and IP layer functionality. 

□ Sub-Interface for an NBMA network. An NBMA network has multiple 
access over the same line but no broadcast capability. Examples of such 
networks are Frame Relay, X.25, and ATM. One physical interface 
comprises one or more sub-interfaces which in turn consist of one or 
more circuits on the physical interface. Sub-interface examples and its 
circuits are: one or more DLCIs forming a sub-interface, one or more 
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X.25 PVC/SVCs forming a sub-interface and one or more VCs of ATM 
forming a sub-interface. This interface shares its physical layer 
functionality with other sub-interfaces, but each sub-interface has its 
own layer-2 (PPP or Frame Relay) and IP layer functionality 

Supported Ports 

□ Single-channel ports: Fast- and GigabitEthernet, Sync and Async serial 

□ Multiple-channel type ports: BRI, Tl /El 

Numbering XSR Slots, Cards, and Ports 

The syntax for slot, card, and port numbering on the CLI is: 
slot#/card#/port# 

These parameters indicate: 

□ slot #: (motherboard is zero), (XSR 1800: 1/2, 3020/3150: 1/2, 3250: 0-2) 

□ card #: NIM card number (FastEth: 1/2, GigaEth: 1-6 from left to right) 

□ port #: NIM port numbers begin with zero 




Slot 0 — ^ ^ — Motherboard 



Figure 2 Slots on the XSR-3250 

Slot, cards, and ports on the motherboard (Slot 0) are expressed as: 

□ Slot 0, Card 1 or 2, Port 1 or 2: 0/1/1-4 or 1/1-4 and 0/2/1-4 or 
2/1-4. The first 0 can be ignored 

Slot, cards, and ports on the first XSR-3250 upper tray slot are expressed as: 

□ Slot 1, Card 1 or 2, Port 1-4: 1/1/1-4 and 1/2/1-4 

Slot, cards, and ports on the second XSR-3250 upper slot are expressed as: 

□ Slot 2, Card 1 or 2, Port 1-4: 2/1/1-4 and 2/2/1-4 
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Setting Port Configuration Mode 

The configuration mode setting for ports on the XSR is as follows: 

□ Single-channel ports are configured in Interface configuration mode. 

□ Multi-channel ports are configured in Controller configuration mode. 
A physical layer data stream is identified by channel using the 
controller command, and this channel group is then configured 
using the interface command. 

Setting Interface Type and Numbering 

Interface types and numbers are set as follows: 

□ Physical-type interface and port numbers are similar. Interface types 
are Serial BRI and PRI (Tl/El), or FastEthernet/GigabitEthernet. 

□ Virtual Interfaces: 

Dial - Range: 0 to 255, Interface type: Dialer. 

- VPN - Range: 0 to 255, Interface type: VPN tunnel /Dialer. 

- Multilink - Range: 1 to 32767, Interface type: VPN tunnel. 

- Frame Relay DLCI - Range: 16 to 1007, Interface type: Serial /FR. 
Sub-interface: Each sub-interface correlates with a physical 
interface, starting at 0. The sub-interface number is Port 
number. sub-inter face number for single channel serial, port 
number. channelgroupnumber.subinterj c ace number for multi-channel. 

Configuration Examples 

The following examples display minimal interface configuration: 

□ FastEthernet Example 

interface fastethernet 1 ^ Begins configuring interface/port 1 
no shutdown ^ Enables the interface 

□ Tl Example 

controller tl 1/0 ^ Begins configuring controller on NIM card 1, port 0 
channel -group 3 timeslots 1, 3-6, 12 

^ Maps timeslots 1, 3, 4, 5, 6, and 12 to channel group 3 
no shutdown ^ Enables the interface 

interface serial 1/0:3 ^ Configures channel group 3 defined above 
encapsulation ppp ^ Sets interface encapsulation type to PPP 
no shutdown ^ Enables the interface 
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□ Tl-PRI (ISDN) Example 

controller tl 1/0/0 ^ Begins configuring PRI NIM card 1, port 0 
pri -group 

^ Enables ISDN, sets all timeslots to map to channel groups on NIM 
controller tl 1/0/0:23 ^ Maps T1 NIM to D-channel sub-interface 
isdn switch -type primary -ni ^ Selects switch type 
isdn pool -member 1 priority 100 

^ Adds a prioritized pool member to sub-interface 

□ Dialer Example 

interface dialer 4 ^ Begins configuring dialer interface 4 

ip address 11.1.2.2 255.0.0.0 

^ Sefs /P address/subnet on dialer port 
dialer pool 5 

^ Sefs c//a/er 4 to use poo/ 5. /fs members are physical ports 

interface serial 2/0 ^ Configures serial interface on NIM card 2, port 0 

encapsulation ppp ^ Sets interface encapsulation type to PPP 

dialer pool member 5 

^ Serial 2/0 is now a member of dialer pool 5 and will eventually be used by dialer 4 
no shutdown ^ Enables the interface 

interface serial 2/1 ^ Configures serial interface on NIM card 2, port 1 
encapsulation ppp ^ Sets interface encapsulation type to PPP 
dialer pool member 5 

^ Serial 2/1 is now a member of dialer pool 5 and will eventually be used by dialer 4 
no shutdown ^ Enables the interface 

□ BRI-Dialer (IDSN) Example 

interface dialer 0 ^ Configures dialer interface 0 

ip address 2.2.2.2 255.255.255.0 ^ Sets IP address/subnet on port 
encapsulation pp+Interf ace/Sub- interface Behavior 

XSR interfaces and sub-interfaces, channels and channel-groups are added 
and deleted differently depending on the particular interface. Interface 
characteristics are as follows: 

□ Tl/El Controller - Creating a channel group adds a serial interface. For 
example, when you issue the command controller tl 1/0, the XSR 
automatically creates channel group 0 with all available timeslots 
assigned to it. You can verify this by checking the running 
configuration where the following entry is displayed: 

interface serial 1/0:0 

You can create other serial objects by creating more channel groups. 
For example, by entering the following commands: 
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channel -group 0 timeslots 1-10 speed 64 
channel-group 1 timeslots 11-20 speed 64 

the following interfaces are added: 

interface serial 1/0:0 
interface serial 1/0:1 

You can delete those controller interfaces only by removing the 
channel groups which automatically created them by entering: 

no channel -group 0 ^ This automatically deletes Serial port 1/0:0 
no channel -group 1 ^ This automatically deletes Serial port 1/0:1 

To delete controller ports and all associated interfaces, you must 
remove the entire controller: 

no controller tl 1/0 

□ PRI NIM - When configuring a PRI interface, a pri group is created as 
follows: 

controller tl 1/0 
pri -group 

Creating a PRI group adds a serial interface internally, but it is not 
visible nor accessible to the user: interface serial 1/0:0 is not 
displayed anywhere. But, the system resources associated with it 
remain in use until the pri group is deleted as follows: 

no pri -group 

□ BRI NIM - When configuring a BRI interface, sub-interface 
addition /removal differs if you are configuring a leased line or 
switched connection. 

Leased line: When configuring a leased line connection, serial 
sub-interfaces are created and are visible to the user: 

interface bri 2/1 

1 eas ed - 1 ine 64 ^ This adds serial port 2/1: 1 
1 eas ed - 1 ine 64 ^ This adds serial port 2/1:2 

These serial interfaces are removed by deleting the entire controller. 
For example: 

interface bri 2/2 
no controller tl 2 
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Switched: When configuring a switched BRI connection, three serial 
sub-interfaces are automatically created when you enter: 

interface bri 2/1 

isdn switch-type basic-nil 

The following sub-interfaces are added: 

interface serial 2/1:0 
interface serial 2/1:1 
interface serial 2/1:2 

These serial sub-interfaces are removed with the no isdn 
switch- type command as follows: 

interface bri 2/1 

no isdn switch- type ^ This deletes serial ports 2/1:0, 2/1:1 and 2/1:2 

Entering Commands that Control Tables 

A number of CLI commands configure entries in tables such as arp and 
access -list in the XSR. Two type of tables are configurable: 

□ Single-instance table: The ARP table, for example, in which one table 
contains many rows and each row is a complete entry Entries are not 
displayed in the same order they are entered. 

□ Multiple-instance table: The Access-List table, for example, in which 
there are multiple tables identified by number with each table 
containing many rows and each row is a complete entry. Entries are 
not displayed in the same order they are entered. 

With few exceptions, you must be in Global mode before issuing table commands. 
Adding Table Entries 

Depending on the type of table configured, the parameter list can be optional 
or required. For example the ARP table has three required parameters and 
some optional values depending on the context. For example, using the 
following command: 

arp ip-address mac -address 

you may type: 

XSR(conf ig) #arp 1.1.1.1 e45e . f f e5 . f f ee 
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where arp is the command and type of table to be filled or modified, l . l . l . l 
is the IP address corresponding to the MAC address e45e. f fe5 . f f ee. 



ARP is a table type, as well as a command, that fills or modifies entries in 
the ARP table. 



A second example is entered as follows: 
XSR (conf ig) #access - list 1 deny any- 
where access -list is the command and the type of table to be filled or 
modified, l is the ID of the table to be modified, deny is the type of operation 
authorized and any is the host that should be denied. 

Deleting Table Entries 

There are two ways to delete an entry from a table depending on the table 
type. For example, typing the following: 

XSR(conf ig) #no arp 1.1.1.1 e45e . f f e5 . f f ee 

removes the arp entry related to row l . l . l . l . where no is the command 
that negates the previous operation and arp is the associated table type. A 
second example is entered as follows: 

XSR (conf ig) #no access-list 1 

removes access-list 1 where no is the command that clears the access -list. 
Modifying Table Entries 

For some tables, you must first remove the entry then add the same entry 
with new values. For the ARP table the syntax is similar to the add command 
where you enter the command and entry ID with a new value which replaces 
the old value in the ARP table. 

For example, typing the following: 

XSR (conf ig) #arp 1.1.1.1 e45e.ffe5.efef 
XSR (conf ig) #arp 1.1.1.1 e45e . f f e5 . 3434 




NOTE 
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first creates an arp entry of l . l . l . l associated with MAC address 

e45e . f f e5 . ef ef . Then, this entry is modified to be associated with the new 

MAC address e45e. f fe5 .3434. 

Displaying Tabie Entries 

You can display ARP table, access-list table, gateway-type prefix table, IP 
routing table, and others at privileged EXEC mode. 

For example, enter show ip arp displays the following output: 
XSR#show ip arp 



Protocol 




Address 




Age (min) 


Hardware Address 


Type 


Interface 


Internet 


192 


.168 


.12. 


16 


0 


0001 


f4fe 


2716 


ARPA 


FastEthernet2 


Internet 


192 


.168 


.14. 


64 


12 


0001 


f 4ee 


2764 


ARPA 


FastEthernet2 


Internet 


192 


.168 


.12. 


40 


18 


OObO 


dOfe 


e292 


ARPA 


FastEthernet2 


Internet 


180 


.180 


.180 


.1 


59 


0030 


eelf 


ef61 


ARPA 


FastEthernet2 


Internet 


192 


.168 


.12. 


1 


8 


OOeO 


631f 


a45a 


ARPA 


FastEthernet2 


Internet 


192 


.168 


.12. 


81 


60 


0030 


85ff 


ef61 


ARPA 


FastEthernet2 


Internet 


192 


.168 


.12. 


17 


44 


0001 


f4ef 


2717 


ARPA 


FastEthernet2 



Managing XSR Interfaces 

You must be in Interface mode before configuring XSR ports. To enter 
Interface mode, type the following, for example: 

XSR#conf igure terminal 

XSR (conf ig) #interf ace FastEthernet 1 

XSR(conf ig-if<Fl>) # 

Ports can be enabled or disabled, configured for default settings, associated 
tables, clock rate, priority group, and encapsulation, for example. Refer to the 
XSR CLI Reference Guide for more details on Interface mode commands. 

i NOTE 

All interfaces are disabled by default. 



Enabling an Interface 

The following command enables an interface. 

XSR (conf ig-if<S2/0>) #no shutdown ^ Enables serial interface 2 
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Disabling an Interface 

An interface can be administratively disabled with the shutdown command: 
XSR (conf ig - if <S2/ 0>) # shutdown ^ Disables interface 

Configuring an Interface 

You can configure an interface only after invoking Interface configuration 
mode. Each interface can be configured with a set of interface-specific 
commands. If you are unsure which commands are available, type ? to list 
them for the particular port. Consider the following sequence of commands 
to configure a GigabitEthernet interface: 

XSR#config terminal 

XSR (conf ig) #interf ace gigabitethernet 2 

XSR(config-if<G2>) #? 

description ^ Text describing this interface 

duplex ^ Manually set the duplex mode 

exit ^ Quit interface configuration mode 

help ^ Description of the interactive help system 

ip ^ Interface Internet Protocol config commands 

loopback ^ Configure interface for internal loopback 

no ^ Negate a command or set its defaults 

shutdown ^ Shutdown the selected interface 

speed ^ Manually set the line speed 

XSR (conf ig- if <F1>) exit ^ Quit Interface mode 

Displaying Interface Attributes 

You can display the current settings of an interface when in Privileged EXEC 
or Global configuration mode. For example, type: 

XSR#show interface fastethernet 1 

or: 

XSR (conf ig) #show interface serial 1/0 
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Managing Message Logs 

Messages produced by the XSR, whether alarms or events, as well as link 
state changes for critical ports and a management authentication log, can be 
routed to various destinations with the logging command. And by issuing 
the no logging command, you can block messages to a site while permitting 
transmission to others. 

For normal operation, you should log only HIGH severity alarms which 
indicate critical events and those requiring operator intervention. Be aware 
that the XSR may drop MEDIUM, LOW, and DEBUG level alarms if the 
system is too busy to deliver them. In that case, the following alarm will be 
generated where XX is the number of messages: 

"Logging Storm Encountered - discarded XX debug/low/medium messages" 
Be aware that the DEBUG alarm level is used by maintenance personnel only. 

The XSR serves the following logging destinations: 

□ Syslog (to remote Syslog server over the network) 

□ Console terminal 

□ Monitor (up to five CLI sessions via Telnet) 

□ Buffer (Log file in XSR's RAM) 

□ Buffer (log file) on CompactFlash card when persistent logging (after 
power loss) is enabled for the firewall (see "Configuring Security on 
the XSR" on page 311 for more information) 

□ SNMP Trap (async notification by XSR to the SNMP Manager) 
Logging Commands 

Logging into individual destinations can be enabled or disabled based on 
severity level of the message (high, medium, low and debug) using the 
logging command. Note that entering logging medium sets that level for all 
destinations. Also, you can display your logging configuration with the show 
logging command and show or clear messages in the memory buffer with 
the show logging history and clear logging commands, respectively. 
The entire message history is lost when the XSR is powered down. 

See "Alarms /Events and System Limits" on page 355 for a thorough listing of 
XSR alarms /events and the XSR CLI Reference Guide for command details. 
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Performing Fault Management 

When a software problem causes the XSR's processor to fail, the system 
captures pertinent data, produces a Fault Report, and restarts the router 
automatically. The Fault Report is useful in diagnosing the problem. The 
router can store one Fault Report, retaining the first Fault Report in case of 
multiple failures. It is stored in a special RAM memory area which is 
preserved if the XSR is rebooted but lost if the router is powered down. 

When the XSR automatically reboots after a crash, the following sample 
message is logged: 

<186>May 29 22:20:59 1.1.1.1 PLATF System warm boot from crash 

Fault Report Commands 

The show fault -report command displays the report. Refer to the XSR CLI 

Reference Guide for more command details. 

Using the Real-Time Clock 

The XSR's Real-Time Clock (RTC) is employed by other system software 
modules to time-stamp events, alarms and is useful when no network clock 
source is accessible. It is normally synchronized with a master clock source 
over the network using the Simple Network Time Protocol (SNTP) but can 
can also synchronize with the battery-supported RTC chip. 

RTC/Network Clock Options 

SNTP synchronizes the RTC with a network master clock but if there is no 
network clock source the RTC clock is used on its own. The RTC maintains 
the correct time with its battery even when the XSR is powered down. 

RTC Commands 

The real-time clock can be set with the clock set command. The universal 
time can be viewed with show clock command. To set the SNTP server, use 
the sntp- client server command. Refer to the XSR CLI Reference Guide for 
more command details. 
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Managing the System Configuration 

The XSR's system configuration consists of three discrete types which are 
described below. The configuration can also be reset to default settings, saved, 
and uploaded or downloaded in bulk fashion. 

□ Factory Default Configuration: These system parameters are set at the 
factory. If you make configuration changes and do not save them or 
the startup configuration file cannot be found, the XSR reverts to the 
factory default configuration. 

□ Startup Configuration: These system settings are used as the current 
running configuration when you power up or issue the reload 
command. The startup configuration is stored in non- volatile (Flash) 
memory as the startup -con fig file. The file contains a version 
number followed by a series of CLI commands. When the XSR 
restarts, each CLI command in this file is read and executed. 

□ Private Configuration: The private -config file contains SNMP v3 
related commands. When the XSR restarts, each CLI command in this 
file is read and executed. The file is updated or created when the 
running configuration is saved to the startup configuration. 

□ Running Configuration: These system settings, known as running - 
config, include a version number followed by accumulated 
commands from startup -config and user revisions. Changes made 
to the configuration are lost if you power cycle or reboot unless you 
save it to startup -config using the copy or write command. 

The XSR validates commands as they are entered and rejects with an error 
message those commands which are invalid. 

Resetting the Configuration to Factory Default 

In situations where the XSR does not have valid software or is experiencing a 
problem booting up, you can reset the router and return it to its factory 
default settings by accessing Bootrom Monitoring Mode. 

Enter Bootrom mode by simultaneously pressing the Ctrl and C keys during 
the first five seconds of system initialization. You can then access a menu 
which allows system initialization from the factory default setting. 

Refer to the XSR CLI Reference Guide and XSR Getting Started Guide for more 
details about Bootrom Monitoring Mode. 
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Using the Default Button 

You can also boot up from the factory default configuration by pressing the 
default button on the rear panel, shown in Figure 3. Doing so will erase the 
content in the startup configuration in Flash memory After pressing the 
default button, the XSR performs the following operations: 

□ Processor is interrupted 

□ Software enforces default configuration as running configuration 

□ Software restarts the XSR 

□ XSR restarts with default configuration 

□ Original startup configuration in Flash is erased 

□ Bootrom password is set to default 

□ Fault report (if any) is cleared 

□ Security-sensitive files are erased from Flash 

□ Bootrom Monitor mode network parameters are set to defaults 

□ Master encryption key is erased from non-volatile memory 

□ Console connection restarts 

^V WARWING 

Pressing the Default button erases all files in Flash memory. 




Figure 3 Default Button 



Configuration Save Options 

There are several options available regarding configuration: 

□ If you want to make your running configuration the new startup 
configuration, you can save it to Flash memory with the copy 
running-conf ig startup-conf ig command. 
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□ If you want to convert your startup configuration into the running 
configuration, you can issue the reload command which reboots the 
XSR and reloads the startup configuration. 

□ If you want to save the startup configuration to a remote site using a 
TFTP server, issue the copy startup -con fig tf tp: command. See 
the associated command below. 

□ If you want to load the configuration manually from a remote site 
using a TFTP server, issue the copy tf tp: star tup -conf ig 
command. Refer to "Bulk Configuration Management " on page 29 
for more information about this and the previous command. 

To view the running-config, use the show running -con fig command. To 
view the startup -conf ig, issue the more startup -conf ig command. 

For more command details, refer to the XSR CLI Reference Guide. 
Using File System Commands 

A set of MS-DOS compatible commands are available for use in conjunction 
with configuration files. The XSR has a file system residing in the XSR's non- 
volatile memory. 

You can copy files with the copy command, remove files with the delete 
command, display files with the more command, verify a packed software 
image file with the verify command, and change and list directory contents 
with the cd and dir commands, respectively. 

For more command details, refer to the XSR CLI Reference Guide. 

Bulk Configuration Management 

The XSR can be configured in one action by storing CLI commands as a script 
in an ASCII file then transferring the file to the router remotely using TFTP or 
locally from cf lash: . There is a limitation in the size of the stored file, 
though. If the file is larger than the limit, then the download operation will 
abort producing an error message. 
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Downloading the Configuration 

Downloading transfers a script file remotely from a server to the XSR's 
startup configuration using TFTP or locally from cf lash: . The ASCII-format 
script can include comments delineated by an exclamation mark. 

To perform the task correctly, the TFTP server must be running on a remote 
device with the configuration file residing in the TFTP root directory of the 
server. You can then enter the copy startup-conf ig tftp: command in 
EXEC mode to copy the configuration file from the server to the XSR. 
Alternately, the file must first be loaded in cf lash: then copied to flash: 
with the copy cf lash: startup-conf ig flash: startup-conf ig command. 



If you have inadvertently added errors to the CLI script file, the 
restoration of startup-conf ig will be stopped at the error line. So, any 
commands after that line in startup-conf ig are not executed. 



For more command details, refer to the XSR CLI Reference Guide. 
Uploading the Configuration 

An upload copies the XSR configuration file (or other files) to a system in a 
CLI script format using TFTP. You can later retrieve the file with TFTP 

To perform the task correctly, the TFTP server must be running on a remote 
device. You then enter the copy startup-conf ig tftp: <tftp IP 
addr>/ filename command in EXEC mode to copy the file to the server. A 
successful upload produces the following sample output: 

XSR#copy startup-conf ig tftp: 

Address of remote host [0.0.0.0] : 10.10.10.10 
Destination file name [startup-conf ig] : 
Copy 1 startup-conf ig' from Flash to server 
as 1 startup-conf ig' (y/n) ? y 

Upload to server done 
File size: 976 bytes 

Refer to the XSR CLI Reference Guide for more command details. 




NOTE 
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Creating Alternate Configuration Files 

The XSR permits you to create multiple configurations, a useful option if you 
want to quickly select one of two configuration files stored in flash: or 
c flash:, for example: star tup -conf ig and star tup -conf igB. The file 
named startup-conf ig is used by the autoboot process. You can use any file 
name for the alternate configuration. 

To make an alternate configuration file available, rename startup-conf ig to 
startup-conf igA (for example), and startup-conf igB to startup- 
conf ig., using the rename command. Then issue the reload command to use 
the new configuration. 

Managing the Software Image 

The XSR can store more than one software image in Flash. 

Creating Alternate Software Image Files 

The XSR lets you create multiple software images, a useful option if you want 
to quickly select an alternate image. For example, you can create two software 
image files: xSRl805_a. f Is and xsrl805_b. f Is. Begin the process by 
issuing the boot system command to create a boot -con fig file containing 
the name of your software file. Enter: 

boot system XSR1805_b . f Is 

The boot - conf ig file contains the file name - xSRl805_a. f Is - used by the 
autoboot process. By changing the file name inside boot-conf ig, you will 
boot from the alternate software file in Flash, xsRl805_b . f is : 

i NOTE 

If the boot from Flash fails for any reason, the XSR will attempt to copy 
the specified software file from the network based on the setting in 
Bootrom mode. Refer to the following section for details. 
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BootRom Upgrade Choices 

There are two methods available to upgrade your Bootrom. If you use the 
Bootrom Update Utility, you will need the updateBootrom. f Is and 
bootromXxx. f Is files. For more information on how to use these files to 
perform your Bootrom upgrade, refer to the Using the Bootrom Update 
Utility section. 

If you do not use the Bootrom Update Utility, you must perform a two-step 
procedure to upgrade from l.xx to 2.xx Bootrom versions due to a change in 
file format. To do so, you will need the bootrom_uncmp . f is and 
bootromX_xxl . f Is files. For more information on how to use these files to 
perform your Bootrom upgrade, refer to the Local Bootrom Upgrade section. 

Pre-upgrade Procedures 

XSR firmware upgrades are infrequent but if you do so using Bootrom mode, 
you must perform the following: 

□ Make a DB-9 null modem serial link to a terminal (HyperTerminal, 
Procomm, et al.) with 9600 bps, 8 bits, 1 stop bit, and no flow control. 

□ Make an Ethernet connection at the first network interface (located 
next to the power switch). 

□ Connect to the FTP (default) or TFTP server on a host PC running 
with a known user and password. Be sure you can access the latest 
Bootrom binary file on the host computer, e.g., bootroml_2l . f Is. 

□ Optionally, if you have CompactFlash installed, you can download the 
firmware file to c flash: then perform Step 1 (see below) followed by 
the bu (lower-case u) command. 

□ If you use the Cabletron TFTP/BOOTP Services application, which 
does not recognize long file names, first shorten the Bootrom file 
name to 8 characters or less with an extension, before beginning the 
download (i.e.: bootnew. f Is). Rename the file after the download. 

□ Be aware that factory default Flash memory is limited to 8 Mbytes 
and if congested may not be able to store a downloaded Bootrom. 
Remove old firmware or other files before downloading. 
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Using the Bootrom Update Utility 

The Bootrom update utility upgrades the boot flash sectors of the on-board 
Flash memory. This update tool functions similar to the bu command but also 
can be executed from a Telnet session, allowing Bootrom updates to be 
performed remotely. The utility runs as a standalone program and can 
recognize both old (1.x) and new (2.01) versions of the Bootrom file format. 
After you complete the Bootrom update, the XSR will reboot. 

Note that screen-captured XSR text is displayed in Courier font. User- 
required input appears in larger, bold Courier font. 

1 From a remote Telnet session, at a CLI prompt, configure the "boot- 
config" file to your current software file residing in flash: (the default is 
xsrisoo.fis; if your Bootrom version is earlier than 1.16, the default 
is xsri805.fis). Enter: 

XSR (conf ig) #boot system xsrl800.fls 

xsrl800.fls saved into flash : boot-config 

2 Exit to EXEC mode and verify this setting by entering: more boot- 
config. Be sure that at least 2 MBytes of flash file space is available 
by entering the dir command. If file space is low, delete unnecessary 
files. The following files are required (xsrisoo . f is may be replaced 
by the current software file): 

XSR-I805#dir 

Listing Directory flash:/ 

size date time name 



208 OCT-31-2002 09:34:16 startup- config 

3244017 OCT-31-2002 09:32:46 xsrl800.fls 
12 OCT-31-2002 09:31:32 boot-config 

3,475,456 bytes free 
6,727,680 bytes total 

3 Using TFTP, transfer the latest Bootrom version from the network. 
The target name must be bootrom. f is : 

XSR-I805#copy 

tftp://192 .168.27 . 95/C : /tf tpDir/bootrom2_01 . f Is 
f lash: bootrom. f Is 
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Copy 1 tf tpDir/bootrom2_01 . f Is 1 from server as ' bootrom . f Is 1 into 
Flash (y/n) ? y 

i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i 

Download from server done 
File size: 820136 bytes 

4 Using TFTP, transfer updateBootrom. f is from the network: 

XSR-1805#copy 

tf tp://192 . 168 .27 . 95/C : /tf tpDir/updateBootrom. f Is 
flash: updateBootrom. f Is 

Copy 1 tf tpDir/updateBootrom . f Is 1 from server 
as ' updateBootrom. f Is 1 into Flash (y/n) ? y 
!!!!!!!!!!!!!!!!!!!!!!!!!! 
Download from server done 
File size: 667172 bytes 

5 Copy boot-conf ig to restore-boot-conf ig: 

XSR-I805#copy f lash:boot-conf ig flash: restore-boot-conf ig 

Copy ' boot-conf ig ' from flash: device 

as ' restore-boot-conf ig ' into flash: device (y/n) ? y 
copying file flash : boot-conf ig -> flash : restore-boot -config 
Copy OK: 12 bytes copied 
12 bytes copied 

6 Reconfigure boot-conf ig to boot updateBootrom. f Is: 

XSR-1805 (config) #boot system updateBootrom. f Is 

updateBootrom. f Is saved into flash : boot-conf ig 

7 Display the current list of files and the contents of boot-conf ig and 
restore-boot-conf ig to verify the transfers went smoothly: 

XSR-I805#dir 

Listing Directory flash:/ 

size date time name 



208 


OCT- 


■31 


-2002 


09 : 


:34 ; 


: 16 


startup -config 


3244017 


OCT- 


■31 


-2002 


09 : 


:32 ; 


:46 


xsrl800 . f Is 


820136 


OCT- 


31 


-2002 


09 : 


:40 : 


:42 


bootrom. f Is 


667172 


OCT- 


31 


-2002 


09 : 


:42 ; 


: 06 


updateBootrom. f Is 


18 


OCT- 


31 


-2002 


09 : 


:44 ; 


: 10 


boot-conf ig 


12 


OCT- 


31 


-2002 


09 : 


:43 : 


:44 


restore-boot-conf ig 



1,984,512 bytes free 
6,727,680 bytes total 
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XSR-I8 05#more boot-config 

updateBootrom. f Is 

XSR-I8 05#more res tore -boot-config 

xsrl800 . f Is 

8 This is a critical step and all previous steps must be completed 
accurately before proceeding. Reload and wait a couple of minutes. 
You will lose your Telnet session as the system reboots. The XSR will 
run updateBootrom. f is and update the Bootrom into the boot flash 
sectors. Power must not be interrupted since a power failure or 
interruption may render the XSR unusable. The file, restore-boot- 
config, will be renamed to boot-config and updateBootrom. f is and 
bootrom. f is will be removed before the router is rebooted again. 

XSR-I805#reload 

Proceed with reload (y/n) ? y 

9 Verify that the system is up by remotely logging in via Telnet. Enter 
show version and check the new Bootrom version. 

Local Bootrom Upgrade 

Due to the change in the format of the Bootrom file between version 1.x and 
version 2.01, a transitional step is required when updating across these 
versions only. This transitional step can be avoided by using the Bootrom 
Update utility described above. 

When you are running a 1.x version of the Bootrom and you try to upgrade to 
version 2.01 of the Bootrom file, it will be rejected due to the change in format. 
bootrom_uncmp. f Is is a transitional, non-redundant Bootrom file that the 
existing l_x version bU command can recognize. By updating and rebooting 
with this transitional version, you can subsequently use the new bu command 
(which recognizes the new 2.01 format) to update the Bootrom to version 2.01. 
Be aware that if you boot with bootrom_uncmp . f Is, you will see the 
following output on the screen: 

"Danger! Cannot find a good copy of Bootrom" 

Once you have upgraded to version 2.01 with bootrom2_0l . f is, you can 
reboot and all subsequent Bootrom updates (which do not involve a change 
in the bootFirst module) are power-safe. 
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In summary, when upgrading 1.x to 2.x Bootrom versions only, you must run 
the bu command twice - first with the bootrom_uncmp . f Is file, then with the 
upgraded Bootrom. Between upgrades you must reboot using bw.. 

To upgrade your firmware using the Local Bootrom Upgrade, perform the 
following steps: 

1 Power on the XSR by flipping the rear switch and observe the front 
LEDs. When the system, VPN, console, NIM1 and NIM2 LEDs turn 
off, immediately enter <Ctrl-C> on the terminal. If you miss this time 
window, power off and try again. The Bootrom monitor menu should 
appear as follows: 

X-Pedition Security Router Bootrom 
Copyright 2003 Enterasys Networks Inc. 

HW Version: 9002854-02 REV0A Serial Number: 2854019876543210 
CPU: IBM PowerPC 405GP Rev. D 
VxWorks version: 5.4 
Bootrom version: 1.21 

Creation date: Nov 3, 2002, 11:16:44 

Cold Start : SystemReset from powerup 
Password : 

Entering ROM monitor Type "h" for help 

Using default Bootrom password The system is not secure!!! 
Use "bp" to change password 

XSR1800 : 

2 Type h or ? to display the command groups. 

3 Type f to list the file command group. 

4 Type n to list the network command group. 

5 Using the np command, assign the following: 

- Local IP address (of the XSR). 

- Remote (host computer) IP address (The host must be on the 
same subnet as the XSR). 

DOS-style full path (without the file name) of the site of the 
Bootrom file on the host computer. 

- The username and password to use when connecting to your FTP 
server on the host computer. 
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6 Verify the network boot values using the sn command. For example: 



XSR: sn 

Local IP address 
Remote IP address 
Remote file path 
Transfer Protocol 
Ftp userid 
Ftp password 
Local target name 
Autoboot 
Quick boot 
Current 4 05 ethernet 



192 . 168 .1.1 
192.168.1.2 
C:/XSR 
FTP 

administrator 
anonymous 
XSR 

enabled 
no 

MAC address is: 



00 : 01 : f 4 : 00 : 01 : 02 
00:01:f4:01:01:03 



Current PCI ethernet MAC address is: 

7 Type b to list the boot command group. 

8 Enter the bu command to transfer the Bootrom image file over FTP 
and upgrade the Bootrom flash sectors to the latest version. Be sure 
to enter the command with an uppercase u and follow the prompts. 



WARNING 



If the Bootrom file transfer is corrupted due to a network interruption, 
this step may render the router unusable. If you suspect this has 
happened, type n at the confirmation prompt to abort erasing and 
replacing the Bootrom. Then, delete the file (type: rm bootroml_21.fls, 
for example) and re-issue the bU command to transfer the image 
again.Here is a sample session: 



XSR1800: bU bootrom_uncmp . f Is 

ftp RETR 192 . 168 . 1 . 2 : c : /XSR1850/ bootrom_uncmp . f Is into 
flash bootrom_uncmp . f Is 

Saved 818448 bytes to flash: bootrom_uncmp . f Is 

Checking bootrom_uncmp . f Is . . . 

Updating bootrom with file, "bootrom_uncmp . f Is " . 

Proceed with erasing current Bootrom in flash and replace with 

bootrom_uncmp . f Is? (y/n) y 

**************************************************** 

* Do not interrupt or power down until complete! * 
***************************************************** 

Erasing 3 sectors at address=0xf f f 20000 
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Programming 131072(0x20000) bytes at address 0xfff20000 
Programming 131072(0x20000) bytes at address 0xfff40000 
Programming 48299 ( Oxbcab) bytes at address Oxfff 60000 
Verifying Bootrom flash sectors 
Locking 3 Bootrom flash sectors 

Second copy of Bootrom . . . 

Erasing 3 sectors at address=0xf f f 80000 

Programming 131072(0x20000) bytes at address Oxfff 80000 
Programming 131072(0x20000) bytes at address OxfffaOOOO 
Programming 48299 ( Oxbcab) bytes at address OxfffcOOOO 
Verifying Bootrom flash sectors 
Locking 3 Bootrom flash sectors 

Locking 8 Bootrom flash sectors 



Do you want to remove the bootrom file bootrom_uncmp . f Is? (y/n) y 

Using default Bootrom password. The system is not secure!!! 
Use "bp" to change password 

9 Reboot the XSR by entering bw. 

10 Repeat Step 8 with: bu bootrom2_01 . f Is 

11 Reboot the XSR again: bw 

12 Your Bootrom in Flash memory is now updated and will be used 
during the next power up sequence. 



For more information, consult the SSR boot Release Notes at: 

http: //www. enterasys . com/support/relnotes/rn_3 033 -05 .pdf 



Loading Software Images 

If the XSR has a valid Bootrom but no valid firmware, the software can be 
loaded from Bootrom Monitor mode using FTP. You also have the option of 
copying the image remotely from a TFTP server, using the copy tf tp : 
flash: command, or locally from cf lash:, using the copy cf lash: 
command. Be aware that should the transfer fail, the XSR may temporarily be 



Bootrom update completed. 



* * * * * 




NOTE 
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without valid software in flash: and should not be reloaded or powered 
down until a new image is downloaded. Also, the CLI session which initiated 
the copy command is blocked during a TFTP download, with a character 
repeatedly shown on screen to indicate a file transfer in progress. 

Software Image Commands 

You can view the status of the software image including such information as 
the current firmware image filename, software release version, timestamp, and 
size by issuing the show version command. 

Use the boot system command to actively change the default file name of the 
software image. 

For more command details, refer to the XSR CLI Reference Guide. 

Displaying System Status and Statistics 

The XSR's numerous show commands, which are available in either 
privileged EXEC or Global configuration mode, display a broad array of 
system data such as: 

□ System name, port types and their status, CPU card revision, Flash 
memory and DRAM size, NIM cards and type, contact and system 
hardware data, image in Flash, system location, and other values. 

□ XSR statistics: buffer counters, packets and NIM card status. 

To display available show commands, issue the show ? command. 

Some system data such as the product type and serial number, hardware 
revision number of the motherboard, and Ethernet port MAC addresses is 
stored in IDROM, a discrete area in Flash memory. You can view these 
parameters by issuing the show version command. 

Refer to the XSR CLI Reference Guide for details about these commands. 
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Network Management through SNMP 

XSR system monitoring provides for the SNMP vl agent (READ-ONLY) 
including gets and limited sets and SNMP v3 gets and sets. Standard MIB II 
modules are supported as well as Enterasys MIBs, as listed in the following 
table. Proprietary MIBs are available via download at: 
http : //www. enterasys . com/ support /mibs 

Table 5 XSR Standard and Proprietary MIBs 



MIB Module 


Document 


Comments 


MIB-II 


RFC-1212 


The egpNeighTable and atTable MIBs are not supported. 
Query ipNetToMediaTable for address translation data. 


Evolution of the Interface 
Group of MIB-II 


RFC-1573 


Translated to SMIvl . Supports ifStackTable only. 


Upload/Download 


Enterasys 


Proprietary MIB: ctron- download- mi b 


Chassis 


Enterasys 


Proprietary MIB: chassis -mib partially supported. 


Entity 


RFC-2737 


Translated to SMIvl. EntPhysicalTable is supported only. 


Tunnel 


RFC-2667 


The tunnellf Table is supported when VPN is enabled. 


SNMPv3 MIB: Framework 


RFC-3411 


Standard MIB 


SNMPv3 MIB: MPD 


RFC-3412 


Standard MIB 


SNMPv3 MIB: USM 


RFC-3414 


Standard MIB 


SNMPv3 MIB: VACM 


RFC-3415 


Standard MIB 


Timed-Reset 


Enterasys 


Proprietary MIB 


Configuration Change 


Enterasys 


Proprietary MIB 


Configuration Management 


Enterasys 


Proprietary MIB 


Syslog Client 


Enterasys 


Proprietary MIB 


SNMP Persistence 


Enterasys 


Proprietary MIB 



In order to use SNMP to gather statistics or configure the device, first 
configure the XSR's SNMP agent with the snmp- server commands. 
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Variables to be configured include: community name, traps, and host. SNMP v3 
support includes options to specify an enginelD, security values for users and 
groups, and associated show commands. Also, the snmp- server view 
command is an especially powerful tool to display SNMP objects either via 
their SNMP term or numerical ID. SNMP v3 data is stored in the private - 
conf ig file in Flash. Although SNMP is disabled by default, entering any 
SNMP configuration command except snmp- server disable will enable the 
SNMP server. 

For a full description of SNMP commands, refer to the XSR CLI Reference 
Guide. Also refer to NetSight Atlas Router Services Manager v2.0 
documentation to query and change SNMP values. Because the SNMP 
manager is disabled at boot-up, you must either manually enable the SNMP 
manager using the CLI, or enable it in startup -conf ig. 



NOTE 



The XSR allows a total of 20 read-only and 20 write-only communities. 



Shaping Trap Traffic 

Two controls are available to manage network traffic caused by SNMP traps. 
The first, set by the snmp- server min- trap -spacing command, configures 
minimum spacing between successive traps to ensure that they are spaced 
without causing delay. 

The second control defines the maximum number of traps that can be sent in 
a given time window. The time window is a moving sum of the number of 
traps sent to the network. If the number of traps sent in the previous window- 
time is less than the value set by the snmp- server max- traps -per-window 
command, then more traps can be sent. 

Both methods work simultaneously and independently and only when both 
are satisfied will a trap be sent. Otherwise, traps will be queued and sent as 
soon as conditions satisfy both traffic shaping methods. 

NOTE 

The XSR permits a total of 20 trap servers. 



XSR User's Guide 



41 



Accessing the XSR Through the Web 



Chapter 2 
Managing the XSR 



Accessing the XSR Through the Web 

The XSR via a browser but provide a cursory display of hardware 
configuration data to diagnose the router over the Web. Because the Web 
server is disabled at boot-up, you must either manually enable the Web server 
using the CLI, or enable it in star tup -conf ig. 

The default Web server port is 80. Access to the XSR through the Web is not 
password protected. 

Network Management Tools 

The following tools are useful to manage the XSR over the network. 

NetSight Atlas Router Services Manager v2.0 

XSR firewall and Access Control List(ACL) configuration can performed on 
the NetSight Atlas Router Services Manager v2.0 application. For more 
information, refer to the following URL: 

http: / / www.enterasys.com/ products /management /NSA-RSM-CD/ 

For NetSight Atlas documentation, refer to the following URL: 
http: / / www.enterasys.com/ support/ manuals /netsight.html 

Firmware Upgrade Procedures 

A variety of tools provided by the XSR and Enterasys' NetSight application 
support the following procedures. 

Using the CLI for Downloads 

TFTP can be used to transfer system firmware to the XSR remotely. A TFTP 
server must be running on the remote machine and the firmware image file 
must reside in the TFTP root directory of the server when using the copy 
tf tp filename command. 
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Using SNMP for Downloads 

You can use an SNMP manager to download or upload firmware from a 
remote server, and copy a configuration image file to the XSR. Only run- 
time/online mode downloads are supported. This requires setting the 
ctDLNet Address and ctDLFileName objects and issuing a ctDLOnLineDownLoad 
defined in the CTRON-DOWNLOAD-MIB. For more details refer to the 
following URL: http:/ /www. enterasys.com/support/mibs 

Fault Report 

A fault report can be uploaded through TFTR The mechanism to upload the 
crash report is the same as the one used to upload configuration file. Refer to 
"Performing Fault Management " on page 26 for more information. 

Auto-discovery 

The NetSight Gateway Management Tool can auto-discover an XSR on the 
network using SNMP with the following MIB variables: 

□ SysDesr 

□ SysObjlD 

□ Sysuptime 

NetSight also performs auto-discovery via ping using ICMP ping. 

Statistics 

For SNMP support, SNMP gets are supported as listed in Table 5. Also, refer 
to NetSight Atlas Router Services Manager v2.0 to query and change SNMP 
values. 

Alarm Management (Traps) 

The following events are supported by SNMP traps: link up, link down, warm 
start, cold start, authentication error, and Entity Trap Configuration Change. 

SNMP alarms are listed in Appendix A: "System Alarms and Events" on 
page 357. 
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Software Image Download 

The NetSight Remote Administrator application can download an image to 
the XSR using TFTP. The software image download is initiated through 
NetSight using an SNMP set command, which triggers a TFTP download 
session initiated from the XSR. 

m / wote 

The XSR does not support an off-line download triggered by SNMP That is, 
when you use NetSight to download an image, a dialog box will pop up 
with a check box titled Online download. If the box is unchecked, the SNMP 
request will fail. See NetSight documentation for more information. 



Using SNMP Download with Auto-Reboot Option 

To use this option, you must first enter the following command in Global 
mode to allow a user to reboot the XSR using SNMP: 

XSR(config) #snmp- server system- shutdown 

When a user employs NetSight to download an image, a dialog box will pop 
up with a check box titled Auto reboot. If the box is checked, the XSR will be 
rebooted remotely after the download ends. If the snmp-server system- 
shutdown command were not entered and the remote user chose the auto 
reboot option, the request would fail. 
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Overview of LAN Interfaces 

The XSR supports two 10/100 Base-T FastEthernet ports on the XSR 1800 
Series branch routers and three 10/100/1000 Base-TGigabitEthernet ports on 
the XSR 3000 Series regional routers. All ports are capable of running in half- 
and full-duplex modes, and are ANSI/IEEE 802.3 and ANSI/IEEE 802.3u 
compliant. These ports connect to an Ethernet network for LAN connectivity. 

The Fast/GigabitEthernet interfaces perform the following functions: 

□ Allow the XSR to connect to networks of speeds of 10 Mbps, 100 
Mbps, or 1000 Mbps (using manual settings or auto-negotiation) 

□ Monitor the status of the link: up or down 

□ Allow you to issue interface/ device configuration commands 
through the Command Line Interface (CLI) 

□ Accumulate MIB-II (RFC-1213) interface statistics regarding the 
transmission and reception of bytes and packets 

LAN Features 

The XSR supports the following LAN interface features: 

□ Alarms/ events - For a complete list, refer to "Alarms /Events and 
System Limits" on page 355 in this manual. 

□ Duplex mode is set using the duplex command with the following 
options: 

Half - half-duplex 
Full - full-duplex 
- Auto - auto-negotiation (default) 
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□ Packet filtering - the interface will receive: 

- All broadcast packets 

- All multicast packets 

- Unicast packets which have the MAC addresses of the device 

□ Maximum Receive Unit (MRU) - all frames less than or equal to 1518 
bytes are accepted including the 4-byte FCS. 

□ Oversized packets greater than 1518 bytes are not accepted. 

□ Runt packets of 64 bytes or less are not accepted. 

□ Maximum Transmission Unit (MTU) - all frames less than or equal to 
1518 bytes are accepted. MTU size is set using the ip mtu command. 

□ Speed is enabled using the speed command with the following 
options: 

- 10-10 Mbps 

- 100 - 100 Mbps 

- 1000 - 1000 Mbps 

Auto - Auto-negotiate (default) 

□ Statistics - all MIB-II interface statistics are supported 

□ Clear commands such as clear counters FastEthernet and 
clear counters gigabitethernet, which reset the MIB-II counters, 
and clear interface FastEthernet and clear interface 
GigabitEthernet, which reset the interface counters and facilitate 
interface troubleshooting. 

Configuring the LAN 

Enter the following commands to configure FastEthernet interface 1 on 
network 192.57.99.32: 

XSR (conf ig) #interf ace fastethernet 1 

XSR(config-if<Fl>) #ip address 192.57.99.32 255.255.255.0 
XSR (conf ig-if <F1>) #no shutdown 

Enter the following commands to configure GigabitEthernet interface 2 on 
network 192.168.57.12: 

XSR (conf ig) ttinterf ace gigabitethernet 2 

XSR (conf ig-if <G2>) #ip address 192.168.57.12 255.255.255.0 
XSR (conf ig-if <G2>) #no shutdown 
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MIB Statistics 

The following table reflects MIB-II (RFC-1213) port statistics collected by a 
LAN interface. 

Table 6 MIB-II Interface Statistics 



Variable 


Description 


IfDescr 


Description of the interface. 


IfType 


Tvne of the interface feet once and never ohanaed^ 


IfMtu 


Size of the largest packet that can be sent/received on the interface, 
snecified in bvtes 

ok/\/ vi 1 1 ii i k/ y loo. 


IfSneed 


Estimate of the interface 1 ^ current bandwidth in kilobits ner second 

L— OLII 1 1 C4 Lv Ul LI Iv II llvl IUvt» O vUl 1 w 1 IL k_/ C4 1 1 V^l V V 1 V^l L 1 1 II 1 IMIUUI LO i"^ V_/ W 1 1 V^l 

(will be 10000 or 100000) 


IfPhysAddress 


Interface's address at its protocol sub-layer (the MAC address). 


ifAdminStatus 


Desired state for the interface. 


ifOperStatus 


Current operational status of the interface. 


ifLastChange 


Value of sysUpTime when the interface entered its current 
operational state. 


If In Octets 


Sum of octets received on the interface. 


iTinucastrKts 


Sum of subnetwork-unicast packets delivered to a higher layer 
protocol. 


iflnNUcastPkts 


Sum of non-unicast packets delivered to a higher layer protocol. 


IflnDiscards 


Sum of inbound packets discarded. 


IflnErrors 


Sum of inbound packets that contained errors. 


IfOutOctets 


Sum of octets transmitted on the interface 


ifOutUcastPkts 


Sum of subnetwork-unicast packets sent to the network. 


ifOutNUcastPkts 


Sum of non-unicast packets transmitted to the network. 


IfOutErrors 


Sum of outbound packets that could not be sent due to errors. 


IfOutDiscards 


Sum of outbound packets discarded. 
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Overview of WAN Interfaces 

The XSR supports as many as six serial cards (in an XSR-3250), each of which 
can support four ports for a maximum of 24 serial ports. Each port is 
individually configurable regarding speed, media-type, and protocol. 

The Serial WAN interface performs the following functions: 

□ Transmit packets given by the protocol layer onto a serial link. 

□ Receive packets from a serial link and pass up to the protocol layer. 

□ Allow CLI configuration commands to be issued. 

□ Accumulate all MIB-II (RFC-1213) interface statistics regarding the 
transmission and reception of bytes and packets. 



WAN Features 



The XSR supports the following WAN interface features: 

□ Alarms/events - For a complete list, refer to "Alarms /Events and 
System Limits ,/ on page 355 in this manual. 

□ Interfaces - The following interface types can be configured using the 
media -type command: 

- RS232 (also known as V.28) (default) 

- RS422 (also known as RS-530) 

- RS449 (also known as V.36) 

- RS530A 

- V.35 

- X.21 

□ Either Sync or Async mode is set by using physical - layer. 

□ Encoding - On Sync interfaces, nrzi- encoding sets NRZI encoding 
(NRZ encoding is the default). 

□ Clocking speed - For Sync interfaces, an external clock must be 
provided. Acceptable clock values range from 2400 Hz to 10 MHz. 
For Async interfaces, the clock is internally generated and can be set 
to the following values using clock rate: 

- 2400 Kbps 

- 4800 Kbps 
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- 7200 Kbps 

- 9600 Kbps (default) 
_ U400 Kbps 

- 19200 Kbps 

- 28800 Kbps 

- 38400 Kbps 

- 57600 Kbps 

- 115200 Kbps 

□ Statistics - all MIB-II interface statistics are supported. 

□ Clear commands such as clear counters serial and clear 
interface serial facilitate interface troubleshooting. 

□ Async mode commands such as databits, stopbits, and parity 
provide configuration of the serial line. 

□ Maximum Receive Unit (MRU) is 1504 bytes (including CRC). 

□ Maximum Transmission Unit (MTU) is 1504 bytes (including CRC). 

Configuring the WAN 

Enter the following commands to configure either a synchronous Tl or 
asynchronous Serial interface. For more detailed information on the 
commands used here, refer to the XSR CLI Reference Guide and other chapters 
in this manual. 

The following example configures the synchronous Tl controller on NIM 1, 
port 0 named Acme Tl with the non-default values of ESF framing and B8ZS 
line encoding. It also specifies channel group 1 with mapped timeslots 1-5, 8 
and 9, assigns the local IP address 192.168.1.1 to the channel group and sets 
PPP encapsulation. 

XSR(conf ig) #controller tl 1/0 

XSR (conf ig-controller<Tl/0>) #description Tl "Acme Tl" 
XSR (conf ig-controller<Tl/0>) #f raming esf 
XSR (conf ig-controller<Tll/0>) #linecode b8zs 

XSR (conf ig- control ler<Tll/ 0>) #channel -group 1 timeslots 1-5,8,9 
XSR (conf ig-controller<Tll/0>) #no shutdown 
XSR (conf ig) #interf ace serial 1/0:1 

XSR(config-if<Sl/0:l>) #ip address 192.168.1.1 255.255.255.0 
XSR (conf ig-if <Sl/0 : 1>) #encapsulation ppp 
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XSR (conf ig-if <Sl/0 : 1>) #no shutdown 

The following example configures the asynchronous serial interface on NIM 
2, port 0 with the following non-default values: PPP encapsulation, RS422 
cabling, 57600 bps clock rate, MTU size of 1200 bytes, no parity, 7 databits and 
2 stopbits. It also assigns the local IP address 192.168.1.1 to the interface. 
Although the XSR is not designed to be an access server, you can attach an 
external modem to the serial port and accept async calls as long as the modem 
is configured in "dumb mode" (AT commands are disabled). 

XSR (conf ig) #interf ace serial 2/0 

XSR(config-if<S2/0>)#ip address 192.168.1.1 255.255.255.0 

XSR (conf ig-if <S2/0>) #encapsulation ppp 

XSR (conf ig-if <S2/0>) #physical- layer async 

XSR (conf ig-if <S2/0>) #media-type rs422 

XSR(conf ig-if<S2/0>) #clock rate 57600 

XSR(config-if<S2/0>)#ip mtu 1200 

XSR (conf ig-if <S2/0>) #parity none 

XSR (conf ig-if <S2/0>) #databits 7 

XSR (conf ig-if <S2/0>) #stopbits 2 

XSR (conf ig-if <S2/0>) #no shutdown 

The following example configures the XSR to dial-out (async): 

XSR (conf ig) #interf ace serial 1/0 
XSR (conf ig-if <S2/0>) #encapsulation ppp 
XSR (conf ig-if <S2/0>) #physical - layer async 
XSR (conf ig-if <S2/0>) #dialer pool-member 1 
XSR(config-if<S2/0>)#clock rate 57600 
XSR (conf ig-if <S2/0>) #no shutdown 

XSR (conf ig-if <S2/0>) #interf ace dialerl 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #dialer string 015081234567 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 192.168.1.2 255.255.255.0 
XSR (conf ig-if <D1>) #no shutdown 
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Overview 

The XSR provides a Tl/El subsystem on a single NIM-based 1/ O card with a 
maximum of two installed NIMs. Depending on the card type and series, 
each card can support 1, 2 or 4 Tl or El physical ports. 

You can select either Tl, at 1.544 Mbps interface rate per port, or El, at 
2.048 Mbps interface rate per port. In both operational modes, the interface 
can work either in full rate Tl/El mode (the complete available line interface 
rate is assigned to one user) , fractional Tl/El mode (only one channel group is 
assigned, with less than the total available number of timeslots on a Tl/El 
line configured per physical port) or in channelized mode (more than one 
channel group is configured per physical port). 

In fractional/ channelized mode, up to 31 DSO channels can be assigned on El 
interfaces and up to 24 DSO channels can be assigned on Tl interfaces. The 
rate (line speed) of basic channel (DSO) can be configured at 56 or 64 Kbps. 

Features 

The following features are offered on the Tl/El interfaces: 

□ Integrated CSU/DSU 

□ Full-rate, channelized and fractional 

□ Short and long haul symmetrical line interfaces with 100/120 ohm 
impedance using RJ-45/48C or 49C connectors 

□ Support for local and remote loopback 

□ Support for an IP interface as a loopback (refer to the CLI Reference 
Guide for an example) 

□ Timing - line and internal 

□ Framing - Tl: SF, ESF; El: CRC4, NO-CRC4 
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□ Line encoding - Tl: AMI, B8ZS; El: AMI, HDB3 

□ Data inversion 

□ Loopback Tests - local, network line, network payload, inband FDL 

□ Alarm detection - all levels of alarm/ event detection and signaling 

T1/E1 Subsystem Configuration 

Each Tl/El physical port is represented as a Tl or El controller. This is valid 
for both full rate Tl/El mode and fractional/ channelized modes. Each Tl/El 
physical port (line) can be configured to run in one of the following modes: 

□ Full rate Tl/El mode - full Tl/El line bandwidth is used by one user 

□ Fractional Tl/El mode - only one Channel Group is assigned to one 
Tl/El physical line 

□ Channelized Tl/El mode - more than one Channel Group is 
assigned to one Tl/El physical line 

For both fractional and channelized configurations, each configured Channel 
Group, which might contain individual timeslots or ranges of timeslots, uses 
only one of the available logical channels. All configured Tl/El lines are 
recognized by the system software as serial interfaces. That implies that all of 
the available configuration procedures for interfaces are applicable. Each of 
the serial interfaces can be configured to carry data traffic with PPP encoding. 

Configuring Channelized T1/E1 Interfaces 

Perform the following steps to set up a channelized Tl/El port. This Tl 
example is similar to that for an El controller and associated port. 

1 Specify the card/port address of the controller to be configured: 

XSR(config) #controller tl 1/0 

This command automatically adds a full-rate channel group on port 0 
and acquires Controller mode. Alternatively, you can add a different 
port and manually add a channel group using any of the 24 timeslots. 

2 Specify the clock source for the controller. 

XSR (conf ig-controller<Tll/0>) #clock source line 

The clock source command determines which one of the circuits 
provides the clocking signal. 

3 Specify the controller's framing type: 

XSR (conf ig-controller<Tll/0>) #f raming esf 
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4 Specify the controller's line encoding type: 

XSR (conf ig-controller<Tll/0>) #linecode b8zs 

5 Specify a channel group and map timeslots to the channel group by 
entering the channel-group command. 

XSR (conf ig- control ler<Tll/ 0 >) #channel -group 0 timeslots 1,3-5,8 

The example specifies channel group 0 and maps timeslots \, 3 
through 5, and 8 to channel group 0. 

{ / mote — 

Each channel group is represented as a serial interface and is set 
individually. Channel groups are created as shown above but to configure 
them you must acquire Interface Serial mode as shown below. 



6 Enter the no shutdown command to enable the line. 

XSR (conf ig-controller<Tll/0>) #no shutdown 

7 If IP routing is enabled, assign an IP address and subnet mask to 
the channel group with the interface and ip address commands: 

XSR (conf ig) #interf ace serial 1/0:0 
That is, NIM 1, port 0, and Channel group 0. 

XSR(config-if<Sl/0:0>)#ip address 10.1.16.2 255.255.255.0 

8 Specify the encapsulation protocol to be used over this interface. 

XSR (conf ig-if <Sl/0 : 0>) #encapsulation ppp 

In this example PPP is used. 

9 Add any additional configuration commands required to enable IP- or 
PPP-related protocols and functionality. 

10 Use the no shutdown and exit commands to enable the interface 
and return to configuration mode. Repeat the previous steps to 
configure more channel groups. 

XSR (conf ig-if <Sl/0 : 0>) #no shutdown 
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Troubleshooting T1/E1 Links 

This section describes general procedures for troubleshooting Tl/El lines on 
the XSR. The following flow diagram shows basic steps to perform. 



Execute the 
show controller t1 x 
command 




Use the following commands to 
bring up the T1/E1 controller: 
controller t1 x 
no shutdown 



Loss of Signal/Loss of Frame 
- refer to Figure 5 



Use the following commands to 
turn loopback off: 
controller t1 x 
no loopback 



Alarm analysis 
■ refer to Figures 6 and 7 



Error Events analysis 
- refer to Figure 8 



lfyourT1/E1 controller still 
does not function as desired, 
contact your service/network provider 



Figure 4 General T1/E1 Troubleshooting Flowchart 
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As shown in Figure 4, three troubleshooting actions are defined: 

□ Tl/El Physical Layer (Layer 1) troubleshooting (loss of 
signal/ frame) 

□ Tl/El Alarm Analysis 

□ Tl/El Error Events Analysis 

T1/E1 Physical Layer Troubleshooting 

This section describes the techniques and procedures to troubleshoot Tl/El 
Physical Layer problems. The troubleshooting flowchart below displays the 
procedures described in the following section. 



Loss of Signal 



Loss of Signal/Loss of Frame 



Loss of Frame 



Connect or 
replace the 
cable 





Use the following commands to 
bring up the T1/E1 controller: 
controller t1 x 
framing {SF \ ESF} 



Use the following commands to 
change the LBO: 
cablelength long 

cablelength short 



I 



lfyourT1/E1 controller still 
does not function as desired, 
contact your service/network provider 



Figure 5 T1/E1 Physical Layer (Layer 1) Troubleshooting Flowchart 

The show controller command displays current controller parameters, 
status and statistics data. Most Tl/El errors are caused by incorrectly 
configured lines including line coding, framing, and clock source parameters. 
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When a Tl/El controller (port) is created with an associated channel group, it 
can exist in three states: 

□ Administratively down: 

If you do not enter the no shutdown command when you create the 
controller (port) or enter the shutdown command for an already 
created controller (port), you create all associated channel-groups on 
that controller (port) but they are disabled. 

□ Down: 

If you enter the no shutdown command for the controller in 
Controller mode, all associated channel groups are enabled on the 
physical level but the controller senses an alarm on the line and will 
not pass user data. 

□ Up: 

Only when the associated interface is enabled using the no shutdown 
command in Interface mode does the channel-group become 
operational. This is because there is one-to-one mapping between 
channel groups and interfaces; if an interface is administratively 
down so is its channel group - even if the controller port is up! 

Follow these steps to restart the controller to correct this type of error: 

1 Enter Controller mode. For example: 

XSR(config) #controller tl 1/0 
XSR (conf ig-controller<Tl/0>) # 

2 Restart the controller: 

XSR (conf ig-controller<Tl/0>) #no shutdown 

If the Tl/El controller and line are not up, ensure one of the following 
messages appears in the show controller output: 

□ Receiver has loss of frame (LOF), or 

□ Receiver has loss of signal (LOS) 

Complete the following steps if the receiver has loss of frame: 

1 Ensure the framing format set on the port matches the framing format 
of the line. If needed, change the framing format configuration. 

2 Change the Line Build-Out (LBO) using cablelength long and 
cablelength short commands. If needed, contact your service 
provider for more details on LBO configuration. 
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Complete the following steps if the receiver has a loss of signal: 

1 Ensure the cable between the interface port and the T1/E1 service 
provider equipment is connected correctly. 

2 Check the cable integrity by looking for breaks or other physical 
abnormalities in the cable. 

3 Check the cable connectors. 

T1/E1 Alarm Analysis 

Perform the following steps to troubleshoot for various alarms that can occur 
within the Tl/El subsystem. The following troubleshooting flowchart 
displays the procedures. 



f Receive Remote Alarm 
( Indication (Yellow alarm) 
\^ - refer to Figure 7 



If a Receive Alarm Indication 
Signal (Blue alarm) is reported 
contact your service/network 
provider 



Alarm Analysis 




I 



What kind of alarm is reported? 



If a Transmit Sending Remote Alarm 
(Red alarm) is reported, check 
your settings at the remote end 



i 



lfyourT1/E1 controller still 
does not function as desired, 
contact your service/network provider 



^ /Transmit Alarm Signal^ 



ncing Remote Alarrr^^^ 



(Blue alarm) J 
V - refer to Figure 7 J 



If a Transmit Remote Alarm 
Indication (Yellow alarm) is 

reported, check your 
settings at the remote site 



Figure 6 T1/E1 Alarm Analysis Troubleshooting Flowchart (Part 1) 



Receive Alarm Indication Signal (AIS - Blue Alarm) 

1 Check that the framing format of the T1/E1 controller port matches 
the framing format of the line provided by your service provider. 
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Receive Remote Alarm Indication (RAI - Yellow Alarm) 

1 Insert an external loopback cable into the T1/E1 port. 

2 Use the show controller command to check for alarms. To identify 
the type of the alarm, analyze the log report of the XSR. If alarms are 
reported, contact your service provider. 

3 Remove the external loopback cable and the reconnect T1/E1 line. 

4 Check the cabling. 

5 Power cycle the XSR. 

6 Connect the T1/E1 line to a different port and configure the port with 
the same settings as the line. If the problem does not persist, then the 
fault lies with the port. In this case, contact Technical Support for 
assistance. 

Transmit Remote Alarm Indication (RAI - Yellow Alarm) 

1 Check the settings at the remote end to ensure that they match your 
port settings. 

2 Contact your service provider if the problem persists. 
Transmit Sending Remote Alarm (Red Alarm) 

1 Ensure the framing format configured on the port matches the 
framing format of the line. If not, change the framing format on the 
controller to match the format of the line. 

2 Check the settings at the remote end and ensure that they match 
your port settings. 

3 Contact your service/network provider if the problem persists. 
Transmit Alarm Indication Signal (AIS - Blue Alarm) 

1 Ensure that the framing format configured on the port matches the 
framing format of the line. If not, change the framing format on the 
controller to match the format of the line. 

2 Power cycle the XSR. 

3 Connect the T1/E1 line to a different port. Configure the port with the 
same settings as the line. If the problem persists, perform an external 
loopback test on that port. If the problem persists, contact Technical 
Support for assistance. 
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Receive Remote Alarm Indication 



(Yellow alarm) - 



i 



see Figure 5 J 



Insert external loopback cable 
in the port 




Check the 
cabling 




Connect 
the T1/E1 
line to a 
different 
port 



Perform 
loopback 
test 



Error Events Analysis 
- refer to Figure 7 



Check the 
cabling 



Check the 
settings on 
the remote 
end 



Contact your 
service/ 
network 
provider 




(Transmit Alarm Indication Signal ] 
(Blue alarm) - see Figure 5 ) 



Reconnect the 
T1/E1 line to 
the original 
port 




Power 
cycle the 
XSR 



Connect 
theT1/E1 
line to a 
different 
port 



Perform 
loopback 
test 



Use the following 
commands to set 
framing: 
controller t1 x 
framing {SF \ ESF} 




This problem is fixed 




The port may be 
defective 



Error Events Analysis 
- refer to Figure 7 



Figure 7 T1/E1 Alarm Analysis Troubleshooting Actions Flow (cont.) 
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T1/E1 Error Events Analysis 

This section describes various error events that can occur on Tl/El lines and 
provides troubleshooting information to fix some of these errors. The show 
controller command displays the status and statistics specific to the 
hardware. This information is useful for diagnostic tasks. 

All problems that can occur are captured by the underlying hardware and 
reported by the show controller output. Here are some troubleshooting 
steps you can perform with a flowchart displaying troubleshooting actions. 




Use the following 
commands to set 
source clocking: 
controller t1 x 
clock source line 



Use the command 
below to verify the 
error counter is still 
increasing: 
controller x 



J 



Use the following 
commands to set 
framing: 
controller t1 x 
framing {SF \ ESF} 

IFT1, then change LBO: 
cablelength {long | short} 



Use the command 
below to verify the 
error counter is still 
increasing: 
controller x 



J 



Use the following 
commands to set 
line coding: 
controller t1 x 
linecode {ami \ b8zs} 

IF Tl, then change LBO 
cablelength {long \ short} 



Use the command 
below to verify the 
error counter is still 
increasing: 
controller x 



J 



lfyourT1/E1 controller still 
does not function as desired, 
contact your service/network 
provider 



Figure 8 T1/E1 Error Events Analysis Troubleshooting Flowchart 
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Troubleshooting T1/E1 Links 



^ NOTE 

Statistics displayed with the show controllers command are reset 
every 24 hours. That is, once the port or line is created with the 
controller command, the 24-hour timer starts. 



Slip Seconds Counter Increasing 

If slip seconds are present on the Tl/El line, usually there is a clocking 
problem. Complete the following steps to correct this problem: 

1 Ensure the clock source is derived from the network (source clocking 
extracted from the line). 

2 Set the T1/E1 clock source from Controller mode if needed. 



Framing Loss Seconds Increasing 

If framing loss seconds are present on the Tl/El line, usually there is a 
framing problem. Perform the following steps to correct this problem: 

1 Ensure the framing format configured on the controller port matches 
the framing format of the line. 

2 Set the T1/E1 framing mode from Controller mode if needed. 

3 (T1 Only) Change the line build out (LBO) using the cablelength 
long or cablelength short command if needed. 

Line Code Violations Increasing 

If line code violations are present on the Tl/El line, usually there is a line 
encoding problem. Perform the following steps to correct this problem: 

1 Ensure the line coding format configured on the controller port 
matches the framing format of the line. 

2 Set the T1/E1 linecode mode from Controller mode if needed. 

3 (T1 Only) Change the line build out (LBO) using the cablelength 
long and cablelength short command if needed. 



XSR User's Guide 



61 



5 



Configuring IP 



Overview 

This document describes the IP protocol suite functionality offered by the 
XSR including: 

□ General IP features (ARP, ICMP, TCP, UDP, TFTP, Telnet, SSH, NAT, 
VRRP, et al.) 

□ IP routing (RIP, OSPF, static routing, triggered-on-demand RIP updates) 

□ Applicable MIBs 

□ Configuration examples 

IP protocol, the main protocol of the TCP/IP suite, interconnects systems of 
packet-switched computer communication networks. It transmits TCP, UDP, 
and ICMP information as IP datagrams in a 32-bit addressing scheme where 
an IP address is represented by four fields, each containing 8-bit numbers. IP 
uses three types and five classes of addresses: 

□ Unicast - destined for a single host 

□ Broadcast - destined for all hosts on a given network 

□ Multicast - destined for a set of hosts belonging to a multicast group 

□ Class A, B, and C - used as a pool for unicast addresses 

□ Class D - used for multicast addresses 

□ Class E - reserved for future use 

General IP Features 

The following features are supported on the XSR: 

□ Meets requirements for IPv4 routers - RFC-1812 
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□ Ethernet 802.3 support of SNAP and DIX frame format 

□ Internet Standard Subnetting Procedure (ISSP) - RFC-950 

□ ARP - dynamic, static, and proxy ARP 

□ IP subnet zero (always enabled) 

□ Router ID is always enabled and calculated as the highest non-zero IP 
address among all loopback interfaces or the highest non-zero IP 
address of existing interfaces (configured interfaces) if no loopback 
interfaces are configured. You can configure a loopback address for 
the XSR to be used as the Router ID with the interface loopback 
command. 

□ BOOTP/DHCP relay 

□ Broadcasting: Directed and UDP broadcast forwarding 

□ ICMP 

- ICMP Router Discovery Protocol 

- Destination unreachable message 

- Time exceeded message 

- Parameter problem message 

- Redirect message 

- Echo or echo reply message 

□ TCP 

- Window and acknowledgement 

- TCP maximum segment size 

- Congestion control in TCP/IP 

- TCP extensions for high performance 

- TCP selective acknowledgement option 

□ UDP 

□ Telnet 

□ SSH 

□ TFTP 

□ MTU 

- Path MTU discovery protocol: Support for external MTU 
discovery (i.e., for data passing through the XSR). An ICMP MTU 
size exceeded message is issued if large packets transit the XSR 
with the "don't fragment" bit set. These packets are dropped per 
RFC-1191. Also, the XSR does not originate MTU discovery, that 
is, application data originating in the router. 

- Set MTU size per interface 
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□ IP Interface 

- Numbered interfaces 

- Un-numbered interfaces on point to point links 

- NBMA support 

- Point to multipoint networks 

- Fully meshed networks 

- Secondary IP 

□ Troubleshooting Tools 

- Pin g 
Traceroute 

□ IP Routing 

- RIP 

- Triggered-on-Demand RIP updates 

- OSPF 

- Static routes 

- Default network 

- CIDR (IP classless) 

□ Network Address Translation (NAT) 

□ Virtual Router Redundancy Protocol (VRRP): RFC-2338 and 
Definitions of Managed Objects for the Virtual Router Redundancy 
Protocol: RFC-2787 

ARP and Proxy ARP 

ARP (Address Resolution Protocol) is a link-level protocol which provides a 
mapping between the two different forms of addresses: 32-bit IP addresses 
and hardware addresses used by the data link. The protocol dynamically 
keeps entries in the ARP Table and can accept statically configured entries 
according to RFC-826. 

The arp command adds or deletes permanent entries to the ARP Table while 
the arp- timeout command sets the duration for an ARP entry to stay in the 
ARP table before expiring. 

Proxy ARP, always enabled on the XSR, lets the XSR answer ARP requests on 
one network for a host on another network. The router acts as a proxy agent 
for the destination host, relaying packets to it from other hosts, as defined by 
RFC-1027. It is configured with the ip proxy- arp command. 
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^ NOTE _ 

The XSR supports a total of 516 dynamic ARP entries, 128 ARP requests 
pending, and 200 static ARP entries with the standard memory of 64 
MBytes installed. 



BOOTP/DHCP Relay 

The Bootstrap Protocol (BOOTP) is used by systems with no capability of 
learning their IP addresses. BOOTP requests can be forwarded by routers, not 
necessitating one server on each physical network. Normally, BOOTP/DHCP 
requests are not forwarded, since they are local broadcasts which are not 
designed to be forwarded, and they have an invalid nonroutable IP source 
address, such as 0.0.0.x. But the agent replaces the destination address with a 
helper address, and the source address with its own address, then forwards it. 
You can set the helper address with the ip helper -address command. 

When a BOOTP/DHCP response is received, the packet is sent to the 
requester as a unicast IP packet, according to RFC-951, with clarifications in 
RFC-1532. 

NOTE 



The XSR supports a total of 50 IP helper addresses per interface and 50 IP 
(UDP) forward ports with standard memory (64 MBytes) installed. 



Broadcast 

A broadcast is a packet destined for all hosts on a given network as defined 
by RFC-919 and RFC-922. 

Directed Broadcast 

An IP directed broadcast is a datagram sent to the broadcast address of a 
subnet to which the sending device is not directly attached. The directed 
broadcast is routed through the network as a unicast packet until it arrives at 
the target subnet, where it is converted into a link-layer broadcast. 
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The XSR supports directed broadcast using the ip directed -broadcast 
command. For security purposes, restrictions can be set by defining and 
applying an ACL and by restricting the protocols. There are two types of 
directed broadcasts, described as follows: 

□ A net-directed broadcast specifies a destination address with a host ID 
of all Is. For example, a Class A net-directed broadcast destination 
address isnetid.255.255.255 where the netid is the Class A 
network ID. The XSR forwards it by default. 

□ A subnet-directed broadcast also specifies a destination address with a 
host ID of all Is, but with a specific subnet ID. For example, a Class A 
subnet-directed broadcast destination address is 

netid. subnet id. 255 .255 where netid is the Class A network ID 
and subnetid is the subnet. The XSR forwards it by default. 

Local Broadcast 

A local broadcast is a broadcast to a destination address of all ones - 
255.255.255.255. This broadcast should not be forwarded. It may be: 

□ Consumed by the router, or, 

□ Forwarded using UDP broadcast forwarding. UDP broadcast 
forwarding is a feature that allows XSR to forward a UDP local 
broadcast to one or more new destinations if the UDP port of the 
datagram matches the configured one. The destination address is 
replaced by a configured unicast address, and there is no change in 
the source IP address (except BOOTP/DHCP relay). A total of 50 
UDP broadcast forwarding entries is allowed in the table with 
standard memory installed. 

ICMP 

The Internet Control Message Protocol (ICMP) communicates error messages 
and other conditions that require attention as defined by RFC-792. 

ICMP messages are transmitted in IP datagrams and are usually acted on by 
the IP layer or higher layer protocols (TCP /UDP). The XSR supports these 
message types: ICMP router discovery, destination unreachable, time exceeded, 
parameter problem, redirect, echo or echo reply. 

The XSR also supports the ICMP Router Discovery Protocol (IRDP) which 
dynamically discovers routes to other networks, as defined by RFC-1256. 
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IRDP allows hosts to locate routers and can also infer router locations by 
checking RIP updates. When the XSR operates as a client, router discovery 
packets are generated. When the device operates as a host, router discovery 
packets are received. The IRDP client/ server implementation does not 
actually examine or store full routing tables sent by routing devices, it merely 
keeps track of which systems are sending such data. 

Using IRDP, the XSR can specify both a priority and the time after which a 
device should be assumed down if no further packets are received. 

The XSR enables router discovery and associated values with the ip irdp 
command. The router also supports the redirection of packets routed through 
the same port they were received on with the ip redirect command. 

TCP 

The Transmission Control Protocol (TCP) is a transport layer language providing 
a connection-oriented, reliable, byte-stream service described by RFC-793. 

UDP 

The User Datagram Protocol (UDP) is a simple, datagram-oriented, transport 
layer protocol where each operation by a process produces exactly one UDP 
datagram, which causes one IP datagram to be sent. RFC-768 describes UDP. 

Telnet 

Telnet provides a general, bi-directional, 8-bit byte-oriented communications 
facility that is always enabled on the XSR. It is a standard method by which 
terminal devices and terminal-oriented processes interface, as described by 
RFC-854. A Telnet connection is a TCP connection used to transmit data with 
interspersed Telnet control data. Two entities compose a Telnet link: 

□ A Telnet server is the host which provides some service 

□ A Telnet user is the host which initiates communications 

Telnet port (23) and server settings can be configured on the XSR with the ip 
telnet port and ip telnet server commands. You can also configure 
Telnet client service to other servers with the telnet ip_address command. 
Refer to the XSR CLI Reference Guide for more information. 
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SSH 

The Secure Shell (SSH) protocol provides for safe remote login and other 
network services on the XSR. Along with a user-supplied client, the SSHv2 
server allows you to establish a secure connection, similar to that provided by 
an inbound Telnet connection with an important exception. 

Unlike Telnet, SSH encrypts the entire connection with the XSR to hide your 
identity, provides data confidentiality via the negotiated choice of encryption 
types such as 3DES, and offers message integrity through hashing using 
SHA-1 or other algorithms such as MD5 or crypto library support for third- 
party encryption ciphers such as Blowfish, Twofish, AES, CAST and 
ARCfour. Enabled (by default) on the CLI with the ip ssh server 
command, SSH is further configured by specifying users, passwords, 
privilege level and policy with the aaa user, password, privilege 15 and 
policy commands, the idle timeout interval for your SSH session with the 
session- timeout ssh command, and user authentication with the aaa SSH 
command. 

Upon configuring the XSR for the first time, you should generate a host key 
pair with the crypto key dsa command, otherwise, if no key is generated, 
the default key is used for any connection request. Generated host keys are 
encrypted and stored in the hostkey.dat file within Flash where the file cannot 
be read or copied. All SSH connection requests use the host keys stored in the 
hostkey.dat file unless none have been generated or the content of the file is 
corrupted in which case default keys are used to secure the connection. 

NOTE 

SSH is enabled by default on port 22. Be aware that with SSH enabled, 
traditional facilities such as FTP, TFTP, and Telnet are not disabled so to 
ensure system security, you must disable other communication services. 



A number of SSH clients are commercially available. Enter asys recommends 
the PuTTY client freeware as compatible and easy to configure. For step-by- 
step instructions on installing PuTTY and configuring SSH, refer to Chapter 
13: Configuring Security on the XSR in the XSR User's Guide. 
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Trivial File Transfer Protocol (TFTP) 

TFTP is a bare bones file transfer protocol, as defined by RFC-1350, using 
UDP to simplify transport with less overhead. The XSR provides TFTP client 
functionality using the snmp- server tf tp- server- list and copy <f ile> 
commands. Always enabled on the router, it is useful to save and restore 
configuration files and images. 

Refer to the XSR CLI Reference Guide and the Managing the XSR chapter in this 
manual for more information. 



IP Interface 

IP interfaces are virtual circuits used to pass traffic between a physical port 
and the XSR forwarder. IP interfaces have the following characteristics: 

□ Numbered interfaces have IP addresses assigned to them. 

□ The port can be pinged to monitor its status with the ping command. 

□ Some routing protocols require the interface to have an IP address. 

□ The interface <serial | f astethernet/gigabitethernet | 
dialer | loopback dialer | vpn> command sets all XSR ports. 

□ The XSR supports a total of 42 interfaces. 

□ Un-numbered interfaces are not assigned IP addresses 

- Un-numbered interfaces may be used on point-to-point 
networks. By default, the address used by the unnumbered 
interface when it generates a packet is the router ID, which is the 
address of the highest, non-zero configured loopback interface. 
An unnumbered interface address can be configured to be the 
address of a specified numbered interface. The ip unnumbered 
command sets interface parameters on the XSR. 

- An un-numbered interface cannot be pinged to monitor its status. 

Secondary IP 

Enabling secondary IP allows multiple IP addresses to be configured on the 
same physical network interface and multiple subnets to share one MAC 
address. Secondary addresses are treated largely like primary addresses, but 
not exactly the same, as explained below. 
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Secondary IP can be used when there are insufficient host addresses on a 
particular network segment. Configuring several subnets on the router interface 
which connects the network segment allows you to combine these logical subnets 
into one physical segment and make more host addresses available. 

Interface & Secondary IP 

The XSR supports seconday IP on Ethernet networks only. All other ports, 
including loopback interfaces, support one IP address per interface only. 

An XSR interface can support one primary IP address and multiple secondary 
IP addresses. Including all XSR interfaces, the total of supported secondary IP 
addresses allowed depends on the amount of the installed memory, although 
at present ten secondary IP addresses are supported despite the memory size. 
All system interfaces share the pool of secondary addresses. For example, if 
FastEthernet 1 uses eight secondary addresses, FastEthernet 2 is allowed no 
more than two secondary addresses. 

Table 7 



Installed Memory 


Total Secondary IP 
addresses Supported 


16 MBytes 


10 


32 MBytes 


10 


64 MBytes 


10 


128 MBytes 


10 



Secondary IP is subject to the following rules: 

□ Primary and secondary IP addresses on the same interface are not 
allowed to exist in the same subnet, nor allowed to exist in the same 
subnets already occupied by other interfaces. 

□ Packets generated by the XSR, except the route update packet, are 
always sourced by the IP address of the outgoing interface which is in 
the same subnet as the IP address of the next-hop the packet should 
be forwarded to. 

□ All routers on the same segment should share the primary network 
number or some protocols, such as OSPF, may not work properly. 
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□ If any router on a network segment uses a secondary address, all 
other devices on the same segment must also use a secondary address 
from the same network or subnet. Inconsistent use of secondary 
addresses on a network segment can quickly cause routing loops. 

□ Configure the primary IP address before any secondary IP addresses 
on the same interface. Conversely, before a primary address can be 
removed, all secondary IP addresses should be removed. 

□ You can configure OSPF, RIP or static routes on each primary and 
secondary IP address. 

□ A secondary IP address is configured using the ip address 
<address> <mask> {secondary} command. 

ARP & Secondary IP 

For each IP address configured on the interface, including primary and 
secondary IP addresses, the corresponding static ARP entry should be 
maintained in the static ARP table. Primary and secondary IP addresses on 
the same interface share the same MAC address of the interface. 

When an ARP request is received, the destination IP address in the ARP 
packet will be checked against the primary IP and all secondary IP addresses. 
If found, an ARP reply will be sent back with the MAC address of the 
interface. When sending an ARP request, the source IP address used in the 
ARP packet should be on the same subnet as the destination IP. 

ICMP & Secondary IP 

When ICMP Echo packets are received by the XSR, the destination IP address 
is checked against all configured IP addresses including primary and 
secondary addresses. Any ICMP Echo packet addressed to the subnet 
broadcast addresses will be dropped without returning a response. 

ICMP Echo Replies are generated by swapping the destination and source IP 
addresses in the received ICMP Echo packets. 

By default, ICMP Echo packets generated by the XSR's ping command will be 
sourced by the IP address of the outgoing interface which is in the same 
subnet as the IP address of the next-hop the ICMP packet should be 
forwarded to. 



72 



XSR User's Guide 



Chapter 5 
Configuring IP 



General IP Features 



When ICMP Mask request packets are received, the destination IP address 
will be matched against the entire subnet network associated with the 
primary and secondary IP addresses. The matched IP address will then be 
used as the source IP address of the reply packet. 

Routing Table Manager & Secondary IP 

If the interface is up, each primary and secondary IP address will have an 
entry in the routing table as a directly connected route. If the interface is 
rejected or the IP addresses configured on it are removed, the Routing Table 
Manager (RTM) will remove the corresponding route entries in the table. 

If any IP address, including primary and secondaries, is deleted or changed, 
any static route based on the next hop reachable through that IP address will 
be removed from the active routing table. And if the IP address is restored, 
any static route previously removed will be restored in the active table. 

OSPF & Secondary IP 

In OSPF, HELLO messagees use the primary IP address as the source address. 
Adjacencies are set up based on the primary IP address only. Designated 
routers (DR) and back-up DRs use the primary IP as their IP addresses. The 
virtual link uses the primary IP only, as well. 

OSPF can be enabled on primary and secondary IP addresses but should be 
enabled on the primary address first. Also, if OSPF is used for routing, all 
OSPF-enabled secondary addresses of an interface should be configured in 
the same OSPF area as the primary address to function properly. 

OSPF can be selectively enabled on a secondary IP address as long as it is 
already enabled on the primary IP address. 

RIP & Secondary IP 

If RIP is used for routing, route updates should be multicast or broadcast to 
each subnet represented by both the primary and secondary IP addresses. 

If an interface is configured with a secondary IP address and split horizon is 
enabled, route updates learned from one specific network cannot be sent back 
to the same physical network. Only one routing update is sourced per 
network number if split horizon is disabled. 

RIP can be selectively enabled on primary and secondary IP addresses. 
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Unnumbered Interface & Secondary IP 

If an unnumbered interface attempts to borrow an IP address from an 
Ethernet interface upon which a secondary IP address is configured, only the 
primary IP address can be borrowed. Also, sSecondary IP cannot be 
configured on an unnumbered interface. 

NAT & Secondary IP 

Only the primary IP address on the specified interface is used for NAT. 
DHCP & Secondary IP 

DHCP operates in the same manner regardless if secondary IP addresses are 
configured or not. Only one IP pool is employed even if multiple IP addresses 
are configured on a single interface. 

VPN & Secondary IP 

Secondary IP addresses are not supported on VPN virtual interfaces. 

Concerning secondary IP addresses assigned to physical interfaces, if an 
interface constitutes the endpoint of a VPN tunnel, the primary IP address is 
always used as that tunnel endpoint. For the trusted interface upon which 
EZ-IPSec Network Extension Mode is running, only the SPD for the primary 
IP address assigned to the internal interface will be created. 

VRRP & Secondary IP 

Multiple virtual IP addresses per Virtual Router (VR) are available to support 
multiple logical IP subnets on a single LAN segment. Secondary IP interacts 
with the XSR's implementation of the Virtual Router Redundancy Protocol 
(VRRP) as follows: 

□ The primary physical IP address on an interface will be selected as a 
VRRP primary IP address, which is used for VRRP advertisement. 

□ If one of the virtual IP addresses of a VR is the real physical address 
of the interface, all other virtual IP addresses of that VR must also be 
the real physical addresses of that interface. 

□ Conversely, if any virtual IP address is not the real physical address of 
that interface, all virtual IP address of that VR cannot be the real 
physical address of that interface. 
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□ The XSR supports 11 IP addresses per VR (1 primary + 10 secondary) 

□ With four VR's allowed per XSR, you can configure up to 44 virtual IP 
addresses per XSR. 

PPPoE & Secondary IP 

Secondary IP is not supported on PPPoE interfaces. 

Maximum Transmission Unit (MTU) 

MTU is the largest frame size allowed on an interface. It is dictated by the link 
level limit on a particular port. Examples of link layer types are Ethernet 
encapsulation and 802.3 encapsulation. MTU limits the bytes of data that can 
be sent in an IP packet using the ip mtu command. Datagrams exceeding the 
link layer's MTU must be fragmented. The default MTU size is 1500 bytes. 

Refer to the XSR CLI Reference Guide for more information. 
Ping 

Ping is an important debugging tool for testing network layer connectivity 
between a source and destination address. The source represents an IP 
address on the XSR where the command is executed from. The destination 
can be any IP address on the network, including an address on the same 
device where a ping occurs. 

The ping command also allows the packet size to be specified. 
Refer to the XSR CLI Reference Guide for more information. 

Traceroute 

Traceroute is a vital debugging tool which reports the route IP datagrams 
follow to a certain destination. Its output is a complete list of routers that a 
specific datagram crosses to reach its destination, as well as the round time 
trip between the XSR where the Traceroute program runs and each of these 
routers. The traceroute command can be issued by the XSR. 

Refer to the XSR CLI Reference Guide for more information. 
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Routing is one of the most important functions of IP. Routing information, 
which is stored in a routing table, is used by the XSR to determine the route 
for each of the packets that pass through it. The following routing features are 
supported on the XSR: 

□ RIP 

□ OSPF 

□ Static routes 

□ Default network 

□ CIDR (IP classless) 

When you run multiple routing protocols, the XSR assigns a weight to each of 
them. For more information, refer to "Routing Priorities" on page 82. 



RIPvl and v2 

The Routing Information Protocol (RIP) is a distance-vector protocol based on the 
Bellman-Ford algorithm to learn the shortest path between two points in a 
network. RIP is used only on networks whose longest path is 15 hops or less and 
is marked by the following limits on the XSR: 

□ MD5 authentication not supported 

□ Static redistribution permitted only 

□ Total number of static routes, routes, interfaces, and RIP networks 
limited depending on the size of installed memory 

□ Distribution lists require an ACL to be configured 

RIP uses request and response messages. Requests ask for all or part of the 
routing table entries and responses can be sent for one of the following reasons: 

□ Response to a specific query 

□ Regular updates (unsolicited response) 

□ Triggered updates caused by a route change 

RIP specifications are RFC-1058 for RIPvl and RFC-2453 for RIPv2. It is 
supported on the XSR with the following features: 

□ Set globally with the router rip and per interface with the network 
commands: they support RIP on both LAN and WAN interfaces with 
these default values: Receive RIPvl and v2, Transmit RIPvl, no 
redistribution, no filtering and Split Horizon with no poison. 
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□ Redistribute static routes into RIP with the redistribute command. 

□ Split horizon with poisoned reverse enabled with the ip split - 
horizon command. 

□ Triggered updates delivered by default or disabled by the ip rip 
disable- triggered-updates command. 

□ Clear text authentication enabled by the ip rip authentication 
mode command. 



RIP commands configured under Interface mode are independent of 
enabling/ disabling the RIP protocol. 



□ RIP is configurable for: 

- Send only is set by issuing the no received interface command 
to prevent RIP from receiving update packets on a specified port. 

- Receive only is set by issuing the passive interface command 
to prevent RIP from sending update packets on a specified port. 

□ Offset metric parameters - route metrics via RIP. Adding an offset to 
an interface makes it a backup 

□ Route filtering, in association with access lists, is enabled by the 
distribute- list command. 

□ A number of statistical display commands revealing RIP counters 
including show ip traffic, show ip route, show ip protocols. 



Triggered-on-Demand RIP 

Triggered-on-demand RIP (defined in RFC-2091) is available for sending 
routing updates on a PPP serial (WAN) port only This feature updates the 
XSR's RIP routing table only when the topology changes or when a next hop's 
reachability is detected on the WAN side of the link. 

This functionality reduces the on-demand WAN circuit's routing traffic and 
allows the link to be brought down when application traffic ceases. Regular 
RIP updates would prevent the connection from being torn down when 
application use ends. The following conditions govern the feature's use: 

□ RIP must be enabled. 




NOTE 
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□ IP split horizon must be enabled (default). Whether poison is enabled 
or not, triggered on demand will still send its updates with poison. 

Triggered-on-demand RIP on the XSR is implemented by the following: 

□ ip rip triggered-on-demand enables the functionality on a per 
interface basis. 

□ ip rip disable- triggered-updates, with the default enforced 
(triggered updates enabled), invokes triggered updates in a timely 
fashion as described by RFCs-1058 and 2453 (RIP and RIPv2 
protocol). These commands work independently of each other. 



Triggered on demand operates on point-to-point Serial interfaces only. 



□ ip rip max- retransmissions sets the number of retransmissions 
to be sent. 

□ ip rip polling- interval sets the polling period for triggered RIP 
requests. 

How Triggered-on-Demand RIP Works 

To better understand when to configure triggered-on-demand RIP, consider 
how it works. Routing updates are sent on the WAN in the following manner: 

□ The full content of the routing database is sent when: 

An update request has been received. The update is sent only to 
the neighbor requesting it. 

- The XSR is first powered up. The update is sent through all 
interfaces running triggered-on-demand RIP. 

An interface is brought up. The update is sent only out the 
interface which was brought up. 

□ A partial update of the database is sent when: 

- An interface is brought up. The new local route is advertised to 
all other interfaces running triggered-on-demand RIP. 

- An interface is brought down. All routes reachable through the 
interface that went down are advertised as unreachable to the 
other interfaces running triggered-on-demand RIP. 




NOTE 
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□ The latest changes are sent when: 

- The routing database is modified by new data. The latest changes 
are sent through all interfaces running triggered-on-demand RIP. 

RFC-2091 also specifies how packet types are handled: 

□ An update request is defined as a request to a peer system to send its 
entire routing database. It is sent: 

When the XSR is powered up; 

- When an interface is brought up. 

□ An update response is defined as a message containing zero or more 
routes; it is retransmitted at periodic intervals until an update 
acknowledge is received. It is sent: 

In response to an update request. The first response contains no 
routes. Other update responses will not be sent until an update 
acknowledge is received. Then the routing database is sent. 

- At power up. The first update response will contain no routes. 

- When a port comes up. The first response contains no routes. 

- When a port is brought down. 

- When there is fresh routing information to be propagated. 

□ Each update response packet sent to a peer is given a sequence number, 
a 16-bit unsigned integer. 

□ Responses must be received in order. Updates received with a 
sequence number out of order is dropped. Packets are accepted if: 

- A sequence number is one more than the previous; 

- A sequence number is the same as the previous (occurs when the 
ack for the previous was sent, but not received on the other side); 

- The sequence number is 0 (could occur at startup or when it 
wraps around). 

The response sequence number received will be saved and used 
as a starting point. 

□ Resynchronization occurs with every update response. 

□ An update acknowledgment is sent in answer to every update response. 

The RFC delineates route persistency in the routing database as follows. Entries 
learned from a triggered response on participating WAN interfaces are 
permanent, unless certain events occur, in which case entries are marked as 
unreachable and the hold-down timer started. These events are: 

□ A circuit-down event has been received; all routes learned from that 
next hop router are marked unreachable. 
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□ An update packet with the flush flag set is received; all routes learned 
from that next hop router are marked unreachable. 

□ An excessive number of retransmissions of an update go 
unacknowledged. All routes learned from that next hop router are 
marked unreachable. 

□ An update response for an expired route comes in. That route is 
marked unreachable. 

The XSR does not retain alternative routes as they are not needed for the 
following scenarios: 

□ Dialer and dialer backup connections, which are not both up at the 
same time. Dialer backup is implemented only when the dialer 
interface goes down (the best route is lost; the back up interface is 
brought up, then an update request and reply are issued and the new 
route installed). 

□ Dial-on-demand connections. 

Retransmissions are governed by the following conditions, among others: 

□ The retransmission timer is a periodic timer set to 5 seconds. 

□ A limit in the number of retransmissions will be set, after which the 
routes learned through the specified circuit are marked as 
unreachable. The maximum number of retransmissions is 
configurable. The default value is 36. 

□ After the maximum number of retransmissions has been reached, 
requests will continue to be sent out with a polling interval whose 
default value is 30 seconds. This value is also configurable. Polling 
will continue until a response is received. 

OSPF 

The Open Shortest Path First (OSPF) routing protocol is a link-state protocol 
as defined by RFC-2328. It supports a replicated database approach to routing 
where each router has a copy of the database and contributes information to 
the database describing the local environment of linked routers. 

All routers piece together the data to obtain a current map of the network. 
The shortest path is calculated using an algorithm based on information in 
the database. 
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OSPF is superior to RIP because as a link-state protocol, it converges faster 
than RIP, a distance-vector protocol; OSPF's longest path is not limited as is 
RIP's (to 15); OSPF supports subnets - a subnet mask is associated with each 
advertised route. The XSR's implementation of OSPF permits static route 
distribution only and is limited by the size of installed memory for the 
following functionality: 

□ Total route ceiling 

□ Total AS external (types 5 and 7) 

□ Total LSA types 1 to 4 



CAUTION 




Your router must be installed within the network in such a way that the 
above limits are not exceeded. 



^ NOTE _ 

OSPF does not learn neighbors over unnumbered WAN interfaces with 
Firewall functionality enabled. 



OSPF is supported on the XSR by the following features: 

□ Set globally with the router ospf and per port with the network 
<ip address> area commands: they support OSPF on LAN and 
WAN interfaces with these defaults: no authentication, cost 10 (LAN) 
or Serial (64), dead interval of 40 seconds, hello interval of 10 seconds, 
priority 1, and 5-second retransmit interval. 

□ Intra- and inter-area, and Type 1 and 2 external routing 

□ Broadcast, point-to-point and point to multi-point models 

□ Protocol enabled /disabled with the router ospf command 

□ Area IDs identified and defined with the network command 

□ Address ranges used by ABRs defined by area range command 

□ OSPF priority with the ip ospf priority command 

□ Cost to send a packet over interface with ip ospf cost command 
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□ Cost for default route sent into a stub area with the area default 
cost command 

□ Stub and NSSA set with the area stub and area nssa commands 

□ Opaque link state advertisement (LSA) option 

□ Manual and automatic virtual links enabled with the area virtual 
link command 

□ MD5 authentication enabled per interface with the area 
authentication and ip ospf message -digest -key commands 

□ Incremental SPF is always enabled. SPF calculation can be changed 
with the timers spf command 

□ Hello wait intervals with the ip ospf dead- interval and ip ospf 
hello- interval commands 

□ Retransmission and link-state update intervals with the ip ospf 
retransmi t- interval and ip ospf transmit -delay commands 

□ A host of statistical display commands including: show ip ospf 
border routers, show ip ospf database, show ip ospf 
interface, show ip ospf neighbor, show ip ospf virtual 
links, show ip protocols, and show ip route 

Refer to the XSR CLI Reference Guide for more information and this chapter for 
a sample OSPF configuration. 

Static Routes 

Static routes are used when a dynamic route to a destination cannot be set up 
or to specify what the XSR will route to. The XSR sets static routes with the ip 
route command. Refer to the XSR CLI Reference Guide for more information 
and a sample static route configuration. 

i NOTE 

The number of static routes is limited by the size of installed memory. 



Routing Priorities 

When you have enabled multiple routing protocols or set up static routes and 
enabled dynamic routes, the XSR prioritizes these routes in the following 
order - 10 is the highest priority. Priorities are not configurable. 
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□ LOCAL 10 

□ STATIC 9 

□ OSPF INTRA 7 

□ OSPFJNTER6 

□ OSPF_EXT4 

□ PREF_RIP4 

Default Network 

The default network is used to specify candidates for the default route when a 
default route (0.0.0.0) is not specified or learned. If the network specified by 
the ip default -network command appears in the routing table from any 
source (dynamic or static), it is flagged as a candidate default route and is 
subject to being chosen as the default route for the XSR. 

You may enter ip default -network multiple times. All candidate default 
routes appear in the routing table preceded by an asterisk. If the network 
specified is a subnet, default routing applies only to the classfull network. If a 
directly connected interface is specified, RIP will generate a default route. 

If the XSR has no interface on the default network, but it has a route to it, it 
will consider this network as a candidate default route for itself. Route 
candidates will be examined and the best one chosen based on administrative 
distance and metric. 

The gateway to the best default path will be named the gateway of last resort 
for the router. The gateway of last resort is the gateway for the route used by 
packets as the last possible alternative, when there is no route to the 
destination, including a default route. 

Refer to the XSR CLI Reference Guide for more information and a sample 
default route configuration. 

Classless Inter-Domain Routing (CIDR) 

CIDR is an advanced addres scheme for the Internet allowing more efficient 
allocation of IP addresses than the earlier A, B, and C address scheme. CIDR 
currently uses prefixes anywhere from 13 to 27 bits. This allows for address 
assignments that much more closely fit an organization's specific needs. 
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CIDR addressing also enables route aggregation in which a single high level 
route entry can represent many lower-level routes in the global routing 
tables. This reduces the routing table size. The XSR supports CIDR which is 
always enabled. The ip address <0-32> command implements CIDR. 

Network Address Translation 

Network Address Translation (NAT) maps IP address from one address realm 
to another, providing transparent routing to end hosts. Using Port and 
Address Translation (NAPT), the protocol provides a way for many users to 
share one global IP address. NAT also enhances access security by only 
allowing certain global addresses to access the private network. 

NAT is limited in some respects: it requires additional processing in the fast 
path which can impact packet delivery speed. Also, applications which 
bundle the host IP address inside the payload do not interoperate with NAT 
because the host IP address does not match the address on the IP header. A 
special translation agent known as an Application Level Gateway (ALG) is 
employed to allow such programs on a host in one address realm to 
transparently connect to its counterpart running on a host in a different realm. 

The XSR implements traditional NAT (RFC-3022). It has two forms: 

□ Basic NAT - Hosts on the private network are mapped statically to 
global addresses. There are two kinds of basic NAT: 

- One-to-one mapping - Each host is supplied a one-to-one mapping, 
on the private network, to a global address. Hosts without 
mappings are not NATted. 

Pool mapping - A pool of global addresses is defined. Hosts on the 
private network are mapped to global addresses on a first-come, 
first-serve basis. Once a global address is selected, static mapping 
is performed. 

□ NAPT - Both the source address and source port of hosts on the 
private network are translated. The global address is that of the 
egress interface. Hosts on the private network all share the same 
global address (based on the egress interface). 

Features 

The following NAT features are supported on the XSR: 

□ Basic NAT - One-to-one mapping based on global (independent of 
interface) static mapping table. Mapping is permanent and is deleted 
only if the configuration is removed. 
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□ Port and Address Translation (NAPT) 

□ Standard Access Control Lists (1-99) only supported 

□ Application Level Gateway (ALG): 

- FTP 

- ICMP 

- Netbios over TCP and UDP 

□ Multiple ISP - NAPT based on the egress interface 

□ With NAPT, routing is not automatically filtered out. Use distribution 
lists to ensure global networks are advertised out of external ports. 

□ NAPT can be configured for VPN interfaces. 

□ IPSec support 

Out-bound packets are processed first by NAT, then forwarded to 
IPSec for encryption. 

- In-bound packets are processed by NAT after IPSec decryption. 

Virtual Router Redundancy Protocol 

The Virtual Router Redundancy Protocol (VRRP) provides redundancy and 
load sharing of multiple IP default gateways on a single LAN without 
requiring that LAN's hosts to run a routing protocol. VRRP configures 
multiple IP routers on one broadcast LAN to form a single Virtual Router 
(VR), which has both a unique virtual IP and virtual MAC address. 

The advantage of this protocol is that hosts on a LAN can switch from one IP 
router to another (in case of failure) without changing their routing 
configuration or running additional protocols. Load balancing can also be 
implemented by configuring multiple VRRP routers across multiple IP 
routers, with each IP router being the master of a different virtual router. 

VRRP is an alternative to dynamic types of router discovery such as proxy 
ARP, RIP and IRDP in that it specifies a group of statically configured default 
gateways on the client. For example, Figure 9 below shows a LAN topology 
where XSRs 1 and 2 are VRRP routers (running VRRP) comprising one virtual 
router (VRRP group). The IP address of the VR matches that of the Ethernet 
interface of XSR1 (10.10.10.1). 
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VR IP address: 10.10.10.1 

XSR1 XSR2 
VR Master VR Backup 




ClientA ClientB ClientC 



Figure 9 Simple VRRP Topology 

Because the VR uses the IP address of the physical Ethernet interface of XSR1, 
XSR1 becomes the master VR, also known as the IP address owner. XSR1, as the 
master VR, assumes the IP address of the VR and is responsible for 
forwarding packets sent to this IP address. 

Clients A, B, and C are configured with the default gateway IP address of 
10.10.10.1. 

XSR2 is a backup VR. If the master VR fails, XSR2 will take over as the master 
VR and support the connected LAN hosts. When XSR1 comes back on line, it 
assumes the role of master VR again. 

Figure 10 illustrates a topology where VRs XSR1 and XSR2 split outgoing 
traffic between them and provide full system redundancy. ClientA and 
ClientB install a default route to XSRl's VR IP address and ClientC and 
ClientD install a default route to XSR2's VR IP address. Both XSRs serve dual 
master/backup roles. 
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ClientA ClientB ClientC ClientD 
Figure 10 Load Balanced, Redundant VRRP Topology 

VRRP Definitions 

The XSR defines VRRP terms as follows: 

VRRP Router - A router running the Virtual Router Redundancy Protocol. It 
may participate in one or more VRs. 

Virtual Router - An abstract object managed by VRRP that acts as a default 
router for hosts on a shared LAN. It consists of a VR Identifier and a set of 
associated IP address(es) across a common LAN. A VRRP router may back up 
one or more VRs. 

IP Address Owner - The VRRP router that has the VR's IP address (es) as real 
interface address(es). This is the router that, when up, will respond to packets 
addressed to one of these IP addresses for ICMP pings, TCP connections, etc. 

VRRP Primary IP Address - An IP address selected from the set of real interface 
addresses. One possible selection algorithm is to always select the first 
address. VRRP advertisements are always sent using the primary IP address 
as the source of the IP packet. 

Virtual Router Master - The VRRP router that assumes the responsibility of 
forwarding packets sent to the IP address (es) associated with the VR, and 
answers ARP requests for these IP address. Note that if the IP address owner 
is available, then it will always become the master. 
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How the VRRP Works 

Multiple IP routers on a single broadcast LAN comprise a single virtual 
router, which has a unique virtual IP address and virtual MAC address. Hosts 
on the LAN configure the VR as their default router (default gateway). 
Devices that provide support for a VR form a VRRP group. The device acting 
as the VR is designated the master of the group. 

At any one time, only one of the routers acts as the VR, forwarding packets 
from hosts on the LAN. If that router goes down, the VRRP provides a 
method by which one of the other routers in the group can take over the 
virtual IP address and MAC address in a timely manner. 

When the VRRP is started, the IP router sends and receives VRRP 
advertisements until a master is chosen. If the IP router does not become the 
master, it continues to listen to advertisements from the master of the group. 

If the IP router becomes the master of the group, it begins sending VRRP 
advertisements and adds VRRP group information to the interface set. Once 
added, any Ethernet frame for the virtual MAC address is received by the IP 
router. Any ARP requests for the virtual IP address are responded to using 
the virtual MAC address. 

If the IP router ceases to be the group master, it removes the VRRP group 
information from the system and continues to listen for VRRP advertisements 
from the new master. 

Different States of a VRRP Router 

Underlying how VRRP operates are three states the VRRP router experiences: 
initialize, backup, and master. Initialize is the first state and involves the 
following steps: 

□ A VRRP router checks the virtual IP address to learn if it is the master. 

□ If it owns that address, it realizes it is the master and its priority is 255. 

□ If the priority equals 255, the VRRP router advertises itself as the 
master, broadcasts an ARP message to all IP addresses associated 
with the VR's IP address, starts the advertisement timer and 
transitions to the master state. 

□ If priority is less than 255, the VRRP router transitions to backup state. 
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In the backup state, a VRRP router monitors the VR master to confirm it is 
alive, does not respond to ARP requests or accept packets for the IP 
address(es) associated with the VR, and discards packets destined for the 
VR's MAC address. If an advertisement is received that the priority equals 0, 
then the VRRP router performs the following: 

□ Advertises that it is the master VR, 

□ Broadcasts an ARP message with the VR's MAC address to all the IP 
addresses associated with the VR's IP address, 

□ Starts the advertisement timer, 

□ And transitions to the master state. 

□ If an advertisement is received that has a higher priority, or a higher 
IP address (if the priority is the same), then the VRRP router discards 
the advertisement and remains as the master VR. 

In the master state, a VRRP router performs as follows: 

□ Responds to ARP requests or accepts packets for the IP address or 
addresses associated with the VR, 

□ Does not accept packets address to the IP address associated with the 
VR if it is not the owner of the IP address, 

□ Forwards packets destined for the VR's MAC address. 

If a shutdown event is received, the VRRP router advertises a 0 priority. 

If an advertisement with a greater priority or higher IP address (if the priority 
is the same) is received by the virtual master, it experiences the following: 

□ Transitions to a backup state 

□ Cancels the advertisement timer 

If an advertisement is received with the priority lower than local priority, or 
with a lower IP address if the priority is the same, then the VRRP router 
discards the advertisement. 
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VRRP Features 

Multiple Virtual IP Addresses per VR 

The XSR permits specifying multiple virtual IP addresses on the VR (up to 11) 
to support multiple logical IP subnet on a LAN segment. This functionality is 
specified by the vrrp < group > ip command. 

The primary physical IP address in that interface will be selected as a VRRP 
primary IP address, which is used for the VRRP advertisement. The 
advertisement timer is set using the vrrp <group> adver-int command. 

If the one of the virtual IP address of a VR is the real physical address of the 
interface, then all other virtual IP addresses of that VR will also have to be the 
real physical addresses of that interface. 

Obversely, if any of the virtual IP addresses is not the real physical address of 
that interface, then all of the virtual IP address of that VR cannot be the real 
physical address of that interface. 

Multiple VRs Per Router 

The XSR supports multiples VRs per router as follows: 

□ A maximum of four VRs are supported per router. 

□ The scope of a VR is limited to a single LAN segment. 

□ The VR ID can be reused in a different scope. 

Authentication 

The XSR supports one type of authentication - simple password 
authentication - which is meant to avoid careless misconfiguration, not 
provide security. It is invoked with the vrrp <group> authentication 
command. Authentication is set per VR. 

Load Balancing 

The XSR provides load balancing according to the following rules: 

□ Load balancing depends on how your network is designed. 

□ Load balancing is supported by separate physical VRRP routers and 
not supported on the same physical router which has two LAN ports 
on the same LAN segment with the same subnet. 
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ARP Process on a VRRP Router 

Three types of ARP requests can be employed on a VRRP router: Host, Proxy 
and Gratuitous ARP 

Host ARP 

Host ARP performs according to the following rules: 

□ When a host sends an ARP request for one of the VR IP addresses, the 
master VR returns the virtual MAC address (00-00-5e-00-01-VRID). 

□ The backup VR must not respond to the ARP request for one of the 
VR IP addresses. 

□ If the master VR is the IP address owner, when a host sends an ARP 
request for this address, the master VR must respond with the virtual 
MAC address, not the real physical MAC address. 

□ For other IP addresses, the VRRP router must respond with the real 
physical MAC address, regardless of master or backup. 

Proxy ARP 

□ If Proxy ARP is used on a VRRP router, then the master VRRP router 
must advertise the VR MAC address for the VR IP address in the 
proxy ARP message. 

Gratuitous ARP 

Gratuitous ARP behaves in the following manner on a VRRP router: 

□ Each VR sends gratuitous ARP when it becomes the master with 
virtual IP and MAC addresses. One gratuitous ARP is issued per VR 
IP address. 

□ To make the bridge learn the correct VR MAC address, the VR 
masters send gratuitous ARP for every virtual IP address in the 
corresponding VR every 10 seconds. 

Traffic Process on a VRRP Router 

Incoming traffic on a VRRP router is governed by the following rules: 

□ Whether a VRRP router is in a master or backup state, it must receive 
packets with a real physical MAC address as the destination MAC 
address. 
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□ The master VR must receive packets with a virtual MAC address as 
the destination MAC address. 

□ The backup VR must not receive any packets with the virtual MAC 
address as the destination MAC address. 

Outgoing traffic on a VRRP router is governed by the following rules: 

□ Master VR - all traffic, including locally generated or forwarding traffic, 
uses one of the virtual MAC addresses as the source MAC address 
except VRRP protocol packets, which use the corresponding virtual 
MAC address as the source MAC address. For example, if four VRs 
occupy one interface, two are in a master and the others a backup state. 
The VRRP router uses one of the virtual MAC addresses of the master 
VRs as the source MAC address for all traffic transferring over this 
interface, except VRRP protocol packets, which use the corresponding 
virtual MAC address as the source MAC address. 

□ Backup VR - all traffic will use a real physical MAC address as the 
source MAC address. For example, If there are two VRs on one 
interface and both are in the backup state. The VRRP router will use 
the real physical MAC address of this interface as the source MAC 
address for all traffic transferred over this interface. 

ICMP Ping 

RFC-2338 specifies that a VR master that is not the actual address owner 
should not respond to an ICMP ping associated with the virtual IP address. 
The vrrp <group> master-respond-ping command allows the VR master 
to respond to an ICMP ping regardless of actual IP address ownership. 

Interface Monitoring 

This feature, invoked by vrrp <group> track, allows a different router to act 
as the default gateway when a route through the local router is unavailable. 
An interface of a VR (usually the intended master of the VR) is set to monitor 
another interface on the same router, and will refrain from acting as the 
master of the VR if the monitored interface is down. It lowers its VR priority 
to 0, allowing another interface to become the VR master. 

When the monitored interface comes up again, the interface of the VR will 
increase its priority back to the original value, and may become the master VR 
again if pre-emption is enabled with vrrp <group> preempt. You can 
manually set the VR priority level with vrrp <group> priority. 
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When the actual IP address owner of the Virtual IP address releases the 
master state of the VR, it will no longer be able to receive any IP packet 
destined for that address even though the actual interface is still up. This may 
cause routing packets to not reach this interface and cause this interface to be 
considered down by other routers. To avoid this situation, when Interface 
Monitoring is used, be sure that you configure Virtual IP addresses different 
than the actual IP addresses of the interfaces. 

Physical Interface and Physical IP Address Change on a VRRP Router 

The VR will change to the initialize state regardless of the interface state, if you 
configure a VR before configuring the physical IP address, and there will be a 
conflict between the physical IP and VR IP address. 

The VR will change to the initialize state regardless of the interface state, if you 
change the physical IP address on that interface, and this change will also 
create a conflict between the physical IP and VR IP address. 

IETF MIBs Supported 

The XSR supports the following standard MIB-II managed objects: 

□ MIB-II RFC-1213: System, Interfaces, IP, ICMP, TCP, UDP, and SNMP 
groups 

□ RFC-1471: PPP LCP MIB (pppLqrExtnsTable and pppTests not 
supported) 

□ RFC-1473: PPP IP NCP MIB 

□ RFC-1573: IfStackTable only 

□ RFC-1724: RIPv2 MIB 

□ RFC-1850: OSPF MIB 

□ RFC-2115: Frame Relay DTE MIB 

□ RFC-2667: Tunnel MIB 

□ RFC-2737, Entity MIB Version 2: EntPhysicalTable 
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□ SNMPv3 MIBs including: 

- RFC-3411 Framework 

- RFC-3412 MPD 

- RFC-3414 USM 

- RFC-3415 VACM 

Configuring RIP Examples 

The following example enables RIP on both FastEthernet interfaces and a 
serial link of the XSR. The FastEthernet 2 interface is configured to be totally 
passive (updates not sent or received). 

The serial interface uses split horizon with poison reverse while the others use 
split horizon (the default). Authentication mode text is used on Serial 1/0, 
and the key string is Mexico: 

XSR (conf ig) #interf ace fastethernet 1 

XSR(config-if<Fl>) #ip address 192.168.1.1 255.255.255.0 

XSR (conf ig-if <F1>) #no shutdown 

XSR (conf ig) #interf ace fastethernet 2 

XSR (conf ig-if <F2>) #no shutdown 

XSR(config-if<F2>) #ip address 192.169.1.1 255.255.255.0 
XSR (conf ig) #interf ace serial 1/0 

XSR(config-if<Sl/0>)#ip address 192.5.10.2 255.255.255.0 
XSR (conf ig-if <Sl/0>) #ip split-horizon poison 

XSR (conf ig-if <Sl/0>) #ip rip authentication key-string Mexico 
XSR (conf ig-if <Sl/0>) #ip rip authentication mode text 
XSR (conf ig-if <Sl/0>) #encapsulation ppp 
XSR (conf ig-if <Sl/0>) #no shutdown 
XSR (conf ig) #router rip 

XSR (conf ig-router) #network 192 . 168 . 1. 0 

XSR (conf ig-router) #network 192 .169.1.0 

XSR (conf ig-router) #network 192 .5.10.0 

XSR (conf ig-router) #passive-interf ace fastethernet 2 

XSR (conf ig-router) #no receive-interf ace fastethernet 2 

The following RIP example sets an Access Control List (ACL) to allow packets 
from the address of 192.168.1 joo: and 154.68. l.xxx (where xxx are any valid 
numbers) only through the XSR's FastEthernet 1 port. 
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XSR (conf ig) #interf ace FastEthernet 1 
XSR (conf ig-if <Fl>#no shutdown 

XSR(config-if<Fl>)#ip address 192.168.1.100 255.255.255.0 

XSR (conf ig-if <F1>) #ip access-group 1 in 

XSR (conf ig-if <F1>) #ip access-group 1 out 

XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig-if <Sl/0>) #no shutdown 

XSR (conf ig-if <Sl/0>) #media-type V35 

XSR (conf ig-if <Sl/0>) #encapsulate ppp 

XSR(config-if<Sl/0>)#ip address 154.68.1.47 255.255.255.0 

XSR (conf ig) #router rip 

XSR (conf ig-router) #network 154 .68.1.0 

XSR (conf ig-router) #network 192 . 168 . 1. 100 

XSR (conf ig) #access-list 1 permit 192.168.1.0 0.0.0.255 

XSR (conf ig) #access-list 1 permit 154.68.1.0 0.0.0.255 

XSR#copy running-conf ig startup-conf ig 

The following configuration sets up RIPvl with Dynamic Host Configuration 
Protocol (DHCP) Relay enabled. DHCP relay is used when no DHCP server 
exists on the immediate network. 

When a local client sends a DHCP request, the XSR relays this request to the 
appropriate DHCP server specified by the helper-address. After the server 
responds, the XSR relays this response back to the local client. 

As described below, the XSR connects to the PSTN via a Tl connection with 
12 associated channels comprising channel-group 0. This Tl channel group is 
presented to the XSR as a serial port and is configured similarly. 

The Tl (serial port) connection is unnumbered, indicating packets from the Tl 
interface will use the IP address of the Ethernet interface instead of its own. 

XSR (conf ig) #controller tl 0/2/0 

XSR (conf ig-controller<T2/0>) #channel -group 0 timeslots 1-12 
XSR (conf ig-controller<T2/0 : 1-12>) #no shutdown 
XSR (conf ig) #interf ace fastethernet 1 
XSR (conf ig-if <F1>) #no shutdown 

XSR(config-if<Fl>)#ip address 192.168.1.100 255.255.255.0 
XSR(conf ig-if<Fl>) #ip helper-address 154.68.1.1 
XSR (conf ig-if <F1>) #interf ace serial 2/0:0 
XSR (conf ig-if <S2/0 : 0>) #no shutdown 
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XSR (conf ig-if <S2/0 : 0>) #encapsulate ppp 

XSR (conf ig-if <S2/0 : 0>) #ip unnumbered fastethernet 1 

XSR (conf ig) #router rip 

XSR (conf ig-router) #network 192 . 168 . 1. 100 
XSR#copy running-conf ig startup-conf ig 

Configuring Unnumbered IP Serial Interface Example 

The following example configures an X.21-type, serial interface 1/0 as an 
unnumbered serial interface. Serial 1/0 is directed to use the IP address of 
FastEthernet port 1. 

XSR (conf ig) #interf ace fastethernet 1 

XSR(config-if<Fl>)#ip address 192.168.1.1 255.255.255.0 

XSR (conf ig-if <F1>) #no shutdown 

XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig-if <Sl/0>) #media-type x21 

XSR (conf ig-if <Sl/0>) #encapsulation ppp 

XSR (conf ig-if <Sl/0>) #ip unnumbered fastethernet 1 

XSR (conf ig-if <Sl/0>) #no shutdown 

XSR#copy running-conf ig startup-conf ig 

Configuring OSPF Example 

The following is a sample configuration of OSPF which adds three networks 
to OSPF areas including stub and NSSA areas, sets the retransmit interval on 
interface FastEthernet 1 to 9 seconds, specifies the cost of sending traffic on 
interface Serial 1 /0 to 64, and redistributes static routes into OSPF: 

XSR (conf ig) #interf ace FastEthernet 1 
XSR (conf ig-if <F1>) #no shutdown 

XSR(config-if<Fl>)#ip address 192.168.1.100 255.255.255.0 
XSR (conf ig-if <F1>) #ip ospf retransmit- interval 9 
XSR (conf ig) #interf ace FastEthernet 2 
XSR (conf ig-if <F2>) #no shutdown 

XSR(config-if<F2>) #ip address 156.57.99.3 255.255.255.0 
XSR (conf ig) #interf ace serial 1/0 
XSR (conf ig-if <Sl/0>) #no shutdown 
XSR (conf ig-if <Sl/0>) #media-type V35 
XSR (conf ig-if <Sl/0>) #encapsulation ppp 
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XSR(config-if<Sl/0>)#ip address 154.68.1.47 255.255.255.0 
XSR (conf ig-if <Sl/0>) #ip ospf cost 64 
XSR (conf ig) #router ospf 1 

XSR (conf ig- router ) #network 192.168.1.0 0.0.0.255 area 0.0.0.10 

XSR (conf ig-router) #network 154.68.1.0 0.0.0.255 area 0 

XSR (conf ig-router) #area 10 nssa default- information-originate 

XSR (conf ig-router) #network 156.57.99.3 255.255.255.0 area 1 

XSR (conf ig-router) #area 1 stub 

XSR (conf ig-router) #redistribute static 

XSR#copy running-conf ig startup-conf ig 



Basic One-to-One Static NAT 

The following example configures inside source address translation on the 
XSR, as shown in Figure 11 below. 



Configuring NAT Examples 



Inside 



Outside 




Request NAT Table 

SA: 10.1.1.1 Private: 10.1.1.1 
DA: 172.20.1 Global: 200.2.2.1 



After Translation 
SA: 200.2.2.1 
DA: 172.20.2.1 




XSR 



External 
interface 




Internet 





Reply after 
reverse lookup 
SA: 172.20.2.1 

DA: 10.1.1.1 



DA: 200.2.2.1 



Figure 11 NAT Inside Source Translation 



1 The user at 10.1.1.1 opens a connection to host 172.20.2.1. 
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2 The first packet the XSR receives from host 10.1 .1 .1 causes the 
router to check its NAT table. 

3 The XSR replaces the inside local source address of 10.1 .1.1 with the 
global IP address 200.20.2.1 and forwards the packet. 

4 Host 172.20.2.1 receives the packet and responds to IP address 
200.20.2.1. 

5 The XSR receives the packet with the inside global destination IP 
address 200.20.2.1 , it looks in the table, and translates the 
destination address to the inside local destination address 10.1.1.1. 
Then it forwards the packet to 1 0. 1 . 1 . 1 . 

Configuring Static Translation 

Only one command is required to configure NAT because static NAT is 
interface independent. Optionally, you can configure multiple entries in 
the static translation table with the ip nat source static command. 

XSR (conf ig) #ip nat source static local -ip global -ip + Sets the 
static translation 

Network Address and Port Translation 

The following example configures inside source address translation with 
overload (NAPT) on the XSR, as shown in Figure 12. 
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Figure 12 NAT Inside Source Translation with Overload (NAPT) 



Inside source address translation with overload, as shown in figure 
Figure 12, is configured as follows: 

1 The user at 10.1.1.1 opens a connection to host 172.20.2.1. 

2 The first packet that the XSR receives from 10.1.1.1 prompts a check 
of the NAPT table. If no translation entry exists and the address 
10.1.1.1 must be translated, the XSR sets up a translation entry. So 
the router replaces the inside local address 10.1.1.1 with the external 
address 200.20.2.1 and forwards the packet. 

3 Host 172.20.2.1 receives the packet and responds to IP address 
200.2.2.1. 

4 When the XSR receives the packet, it searches the NAPT table, using 
the protocol, global address and port, and translates the address to 



XSR User's Guide 



99 



Configuring VRRP Example 



Chapter 5 
Configuring IP 



the inside local address 10.1.1.1 and destination port 1789, then 
forwards it to 10.1.1.1. 

Configuring NAPT 

The following steps are required to configure overloading of inside global 
addresses. The example configures an access list to permit specified 
traffic but is optional. All other traffic is implicitly denied. 

XSR (conf ig) #interf ace serial 1/0 

^ Configures serial port and acquires Interface mode 

XSR (conf ig-if <S1/ 0>) #ip nat source list 99 assigned overload 
^ Specifies NAT translation rules on the interface 

XSR (conf ig) #access-list 99 permit ip 10.1.1.0 0.0.0.255 
^ Adds ACL to permit IP traffic from the specified source 



Configuring VRRP Example 

The following example configures three VRRP groups to provide 
forwarding redundancy and load balancing on VRRP routers XSRa and 
XSRb as follows: 

□ Group 1: the virtual IP address is 10.10.10.10, XSRa is the group 
master with priority 120, the advertising interval is 3 seconds, 
preemption is enabled with a 2-second delay, and authentication is 
set with the text robo. 

□ Group 5: XSRb is the group master with priority 200, the virtual IP 
address is 10.10.10.50, the advertising interval is 30 seconds, and 
preemption is enabled with a 2-second delay. 

□ Group 100: XSRa is the group master with priority 85, the advertising 
interval is 1 second (default), and preemption is off. 

□ The WAN Serial interface 2/0 is tracked by FastEthernet interface 1 
on each likely master VR. 

Router XSRa 

XSRa (conf ig) #interf ace fastethernet 1/0 

XSRa (conf ig-if <Fl>)#ip address 10.10.10.2 255.255.255.0 
XSRa (conf ig-if <F1>) #vrrp 1 priority 150 
XSRa (conf ig-if <F1>) #vrrp 1 preempt delay 2 
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XSRa (conf ig-if <F1>) #vrrp 1 track serial 2/0 
XSRa (conf ig-if <F1>) #vrrp 1 authentication robo 
XSRa (conf ig-if <F1>) #vrrp 1 adver-int 3 
XSRa (conf ig-if <Fl>)#vrrp 1 ip 10.10.10.10 
XSRa (conf ig-if <F1>) #vrrp 5 priority 100 
XSRa (conf ig-if <F1>) #vrrp 5 adver-int 30 
XSRa (conf ig-if <Fl>)#vrrp 5 ip 10.10.10.50 
XSRa (conf ig-if <F1>) #vrrp 5 preempt delay 2 
XSRa (conf ig-if <Fl>)#vrrp 100 ip 10.10.10.100 
XSRa (conf ig-if <F1>) #vrrp 100 priority 85 
XSRa (conf ig-if <F1>) #no vrrp 100 preempt 
XSRa (conf ig-if <F1>) #vrrp 100 track serial 2/0 
XSRa (conf ig-if <F1>) #no shutdown 

Router XSRb 

XSRb (conf ig) #interf ace fastethernet 1/0 

XSRb (conf ig-if <Fl>)#ip address 10.10.10.1 255.255.255.0 

XSRb (conf ig-if <F1>) #vrrp 1 priority 100 

XSRb (conf ig-if <F1>) #vrrp 1 preempt delay 2 

XSRb (conf ig-if <F1>) #vrrp 1 authentication robo 

XSRb (conf ig-if <F1>) #vrrp 1 adver-int 3 

XSRb (conf ig-if <F1>) #vrrp 1 ip 10.10.10.10 

XSRb (conf ig-if <F1>) #vrrp 5 priority 200 

XSRb (conf ig-if <F1>) #vrrp 5 adver-int 30 

XSRb (conf ig-if <F1>) #vrrp 5 ip 10.10.10.50 

XSRb (conf ig-if <F1>) #vrrp 5 preempt delay 2 

XSRb (conf ig-if <F1>) #vrrp 5 track serial 2/0 

XSRb (conf ig-if <F1>) #vrrp 100 ip 10.10.10.100 

XSRb (conf ig-if <F1>) #vrrp 100 priority 65 

XSRb (conf ig-if <F1>) #no vrrp 100 preempt 

XSRb (conf ig-if <F1>) #no shutdown 
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Overview 

The Point-to-Point Protocol (PPP), referenced in RFC-1616, is a standard 
method for transporting multi-protocol datagrams over point-to-point links. 

PPP defines procedures to assign and manage network addresses, 
asynchronous and synchronous encapsulation, link configuration, link 
quality testing, network protocol multiplexing, error detection, and option 
negotiation for network-layer address and data-compression negotiation. 
PPP provides all these functions through its three main components: 

□ An extensible Link Control Protocol (LCP) for establishing, 
configuring, and testing the data-link connection. 

□ A method for encapsulating multi-protocol datagrams. 

□ A family of Network Control Protocols (NCPs) for establishing and 
configuring different network-layer protocols. 

When negotiation is complete, PPP becomes the pipe that carries the network 
layer protocol data units (PDUs) in the information field of the PPP packet. 
PPP offers high performance and error-free transmission of user traffic from 
sender to receiver over a link. 

PPP Features 

The XSR PPP software module offers the following features: 

□ IP datagram encapsulation over a data link connection 

□ Synchronous and asynchronous communication modes 

□ Multilink Protocol (MP) as defined by RFC-1990 

□ IPCP Network Control Protocol 



XSR User's Guide 



103 



PPP Features 



Chapter 6 
Configuring PPP 



□ Authentication of peer entities through: 

- Password Authentication Protocol (PAP) 

- Challenge Handshake Authentication Protocol (CHAP) 

- Microsoft Challenge Handshake Authentication Protocol (MS- 
CHAP) 

□ Link Quality Monitoring (LQM) procedures as defined by RFC-1989 

□ VJ/IP header compression 

□ No restriction on frame size; default is 1500 octets for the information 
field - as defined by RFC-1661 

□ Self-Describing Padding and FCS (16-bytes) as defined by RFC-1570 

□ Outbound Dialing 

□ 16-bit Fast Check Sequence 

□ The following parameters are negotiated during link level 
configuration (as defined by RFC-1471): 

- Maximum size of the packet that can be received on a link (MRU) 

- Protocol to be used for authentication 

- Asynchronous Character Control Map (ACCM) 

- The protocol to be used for Link Quality Monitoring 

- FCS 

- Magic number 

- Padding 

□ Bandwidth Allocation Protocol (BAP/BACP) as defined by RFC-2125 

Link Control Protocol (LCP) 

The Link Control Protocol (LCP) handles the functions of establishing, 
configuring and terminating the PPP link. These functions are as follows: 

□ Establish, configure and terminate the PPP link. 

□ Initiate authentication and link quality monitoring procedures, if set. 

□ Initiate network layer configuration option negotiation procedures. 

Link level configuration options to be negotiated with the peer are set on per- 
link basis. After the lower layer is operationally up, link establishment and 
configuration negotiation is performed. If a configuration option is not 
included in the LCP packet, the default value for that option is assumed. LCP 
starts authentication and LQM procedures after the link is built. After the link 
is authenticated successfully, configured NCP protocols are initiated. 
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Network Control Protocol (NCP) 

The Network Control Protocol (NCP) handles transmission and reception of 
various network layer control packets and datagrams. NCP provides: 

□ Sets up network layer control protocols over the established PPP link. 

□ Transmits/ receives network layer datagrams if the corresponding 
NCP is successfully negotiated. 

The configuration negotiation procedures are performed once the LCP 
reaches the OPENED state. 

Authentication 

Authentication protocols, as referenced in RFC-1334, are used primarily by 
hosts and routers to connect to a PPP network server via switched circuits or 
dialup lines, but might be applied to dedicated links as well. The server can 
use identification of the connecting host or router to select options for 
network layer negotiations. 

The authentication protocol used is negotiated with the peer entity via LCP 
configuration options. If the authentication option is successfully negotiated, 
the LCP module initiates authentication after link establishment. This module 
performs authentication and the result is communicated to the LCP module. 

If authentication succeeds, LCP informs NCP that the PPP link is operational. 
If authentication fails, it closes the PPP link and generates an error message. 

Password Authentication Protocol (PAP) 

The Password Authentication Protocol (PAP) is a simple method for the peer 
to establish its identity using a two-way handshake. PAP authentication 
occurs only upon initial link establishment. After this phase is complete, the 
peer repeatedly sends an ID /Password pair to the authenticator until 
authentication is acknowledged or the connection closed. 

PAP is not a strong authentication method because passwords are sent over a 
circuit in the clear with no protection from playback or repeated trial and error 
attacks. The peer controls the frequency and timing of authentication 
attempts. 
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PAP is most appropriate where a plaintext password must be available to 
simulate a login at a remote host. In such a use, PAP provides a similar level 
of security to the usual user login at the remote host. 

Challenge Handshake Authentication Protocol (CHAP) 

The Challenge Handshake Authentication Protocol (CHAP), as referenced in 
RFC-1994, periodically verifies the identity of the peer using a 3-way 
handshake. This occurs upon initial link establishment, and may be repeated 
anytime after the link has been established. 

After the link establishment phase is complete, the authenticator sends a 
// challenge ,/ message to the peer. The peer responds with a value calculated 
using a "one-way hash" function. 

The authenticator checks the response against its own calculation of the 
expected hash value. If the values match the connection is accepted, 
otherwise the connection is terminated. CHAP uses MD5 as its hashing 
algorithm. 

CHAP protects against playback attack with an incrementally changing 
identifier and a variable challenge value. The use of repeated challenges is 
intended to limit the time of exposure to any single attack. The authenticator 
controls the frequency and timing of the challenges. 

CHAP depends upon a secret known only to the authenticator and that peer. 
The secret is not sent over the link. CHAP is most likely used where the same 
secret is easily accessed from both ends of the link. 

Microsoft Challenge Handshake Protocol (MS-CHAP) 

MS-CHAP, referenced in RFC-2433, authenticates remote Windows 
workstations, providing the functionality to which LAN-based users are 
accustomed while integrating the encryption and hashing algorithms used on 
Windows networks. MS-CHAP is closely derived from the PPP CHAP with 
the exception that it uses MD4 as its hashing algorithm. 

The MS-CHAP challenge, response and success packet formats are identical 
in format to the standard CHAP challenge, response and success packets, 
respectively. MS-CHAP defines a set of reason for failure codes returned in the 
Failure packet Message Field. 
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It also defines a new packet called Change Password Packet, which enables a 
client to send a response packet based on a new password. An 8-octet 
challenge string is generated using a random number generator. A change 
password packet is sent in response to a failure packet from the peer that 
contains the failure code for change password. 

Currently, MS-CHAP authenticators do not send the name value field in the 
challenge packet but construct the response packet with the first MS-CHAP 
name/ secret pair retrieved from the secret list. When MS-CHAP secrets are 
not configured, a configure NAK will be sent with either CHAP (MD5) or 
PAP protocol in response to a MS-CHAP Authentication protocol option in 
the LCP request from the Windows system. 

Link Quality Monitoring (LQM) 

As referenced in RFC-1989, LQM defines a protocol for generating Link- 
Quality-Reports. These Report packets provide a mechanism to determine 
link quality, but it is up to each implementation to decide when the link is 
usable. LQM carefully defines the Link-Quality-Report packet format and 
specifies reference points to measure all data transmission and reception. 
LQM's functionality includes: 

□ Maintaining LQM statistics and sending them to the peer periodically 

□ Determining link quality based on statistics received from the peer 

□ Suspending traffic over the link, if that link quality is bad 

□ Monitoring suspended link quality by swapping LQM packets with peer 

□ Restoring the link after quality reaches a desired level (set by 
configuration) 

Multilink PPP (MLPPP) 

Multilink PPP (MLPPP), as referenced in RFC-1990, aggregates multiple 
point-to-point links to form a group with higher bandwidth. Multilink is 
based on an LCP option negotiation that permits the XSR to indicate to its 
peer that it is capable of combining multiple physical links into a bundle. 

LCP negotiation indicates the following: 

□ The XSR can combine multiple physical links into one logical link 
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□ The XSR can receive upper layer protocol data units (PDU) 
fragmented using the multilink header and reassemble the fragments 
into the original PDU for processing 

□ The XSR can receive PDUs of size N octets where N is specified as 
part of the option even if N is larger than the maximum receive unit 
(MRU) for a single physical link 

When a packet is transmitted over a multilink bundle it is encapsulated by a 
multilink header, which includes information to allow the packets sent over 
the links in the bundle to be sequenced. 

Functionality provided by MLPPP on the XSR includes: 

□ Learned number of fragments to be sent on each link and the bundle 

□ Fragmentation/ reassembly 

□ Detection of fragment loss 

□ Optimal buffer usage 

□ MTU size determination 

□ Management of MLPPP bundles 

□ MIB support for network management 

□ Up to four Tl/El lines can be aggregated running MLPPP 

IP Control Protocol (IPCP) 

IPCP negotiates the following options, as referenced in RFC-1332: 

□ The IP address of the system 

□ The compression protocol to be applied on IP datagrams (Van 
Jacobson Compressed TCP/IP) 

Along with the above support, the following IPCP extension is also offered: 

□ Primary and Secondary DNS and NBNS address 

Once negotiation is successful, IPCP allows IP traffic over the established PPP 
link. The negotiated IP addresses and MTU of the interface are passed on to 
the higher layer (IP) to update its tables. 
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IP Address Assignment 

In PPP, IPCP configuration option type 3 corresponds to IP address 
negotiation. This configuration option provides a way to negotiate the IP 
address to be used on the local end of the link. 

It allows the sender of the Configure-Request to state which IP address is 
desired, or to request that the peer provide the information. The peer can do 
this by NAKing the option, and returning a valid IP address. If the host wants 
the peer to provide the IP address, it will mark the IP address field as 
configuration option 0. 

Upon receiving an IP-address Configure-Request with IP address field 0, 
IPCP may allocate a valid IP address to the peer by sending a Configure-Nak 
to the received Configure-Request or it may reject the Configure-Request. 

PPP Bandwidth Allocation/Control Protocols (BAP/BAPC) 

The XSR supports the PPP Bandwidth Allocation/ Control protocols 
(BAP/BACP) as a means of managing individual links of a multilink bundle 
as well as specifying which peer is responsible for managing bandwidth 
during a multilink connection. 

This ability to dynamically change bandwidth during a multilink connection is 
referred to as Bandwidth-on-Demand (BoD). For more information on BoD, 
refer to "Configuring Integrated Services Digital Network (ISDN)" on 
page 187 and "Configuring Dialer Services" on page 135. 

BAP/BACP, as defined by RFC-2125, is a flexible, robust method of managing 
bandwidth between two peers. BAP does this by defining Call-Control 
packets and a protocol that allows peers to co-ordinate actual bandwidth 
allocation and de-allocation. Phone number values may be passed in the Call- 
Control packets to minimize user configuration. 

BAP/BACP provides the following benefits: 

□ Allows multilink implementations to interoperate by providing call 
control through the use of link types, speeds, and telephone numbers. 

□ Controls thrashing caused by frequent raising/ tearing down links. 

□ Ensures that both ends of a link are told when links are 
added/ dropped from a multilink bundle. 
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The BACP protocol must reach the Opened state using the standard PPP 
mechanism as defined in RFC-1661. Once BACP reaches the Opened state on 
a bundle, BAP may transmit packets through this PPP/MLPPP pipeline. 

BAP datagrams are encapsulated by the PPP/MLPPP module and 
transmitted across the link. Transmission and reception of BAP and BACP 
packets is through the same interface procedures used by any other NCP 
protocol pair. 

Functionality provided by BAP /BACP is summarized as follows: 

□ To add links: 

- Negotiate phone numbers over the bundles through BAP. 

- Agree with peer before trying to set up a call. 

- Check for available lines before agreeing to add a link. 

- Manage race conditions when both peers wish to add a link. 

□ To delete links: 

- Agree with peer to tear down a link before disconnecting the call. 

Configuring PPP with a Dialed Backup Line 

You can configure PPP on the following types of physical interfaces: 

□ Asynchronous serial 

□ Synchronous serial 

□ Tl/El 

By enabling PPP encapsulation on physical interfaces, PPP can also be used 
on calls placed by the dialer interfaces that use the physical interfaces. Refer 
to Figure 13 for an example of an XSR configured with one backup dial line to 
two different sites. 
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Configuring a Synchronous Serial Interface 




Central Site 



Figure 13 XSR Configuration with One Backup Dial Line to Different Sites 

Configuring a Synchronous Serial Interface 

Perform the following steps to configure a synchronous V.35 serial interface to 
communicate with PPP: 

1 Enter interface serial <cardlport> to specify the interface. 

XSR (conf ig) #interf ace serial 1/0 

2 Enter the media-type for the interface (default: RS232). 

XSR (conf ig-if <Sl/0>) #media-type v35 

3 Enter encapsulation ppp to enable PPP encapsulation. 

XSR (conf ig-if <Sl/0>) #encapsulation ppp 
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4 



Set the local IP address of this interface. 



XSR(config-if<Sl/0>) #ip address 192.168.1.1 255.255.255.0 



5 



Enter no shutdown to enable this interface. 



XSR (conf ig-if <Sl/0>) #no shutdown 



Configuring a 



Dialed Backup Line 



The following tasks must be performed to configure a Dialed Backup line: 

□ Configure the dialer interface 

□ Configure a physical interface to function as backup 

□ Configure primary interfaces to use a backup interface 

Configuring the Dialer Interface 

For more details on configuring Dialer Services, refer to Chapter 7. 

1 Enter interface dialer number to create the dialer interface. 

The number range is 0 to 25. 

2 Enter encapsulation ppp to enable PPP encapsulation. 

3 Enter ppp auth <options> to set the type of authentication. 

The authentication options are chap, pap, or ms-chap. 

4 Enter ppp keepalive seconds to set the keepalive interval. 

5 Enter ppp quality percentage to set the minimum LQM value on the 
interface before it will go down. 

6 Enter dialer pool number to specify the dialer pool. 

The number range is 0 to 255. 

7 Enable the interface by entering the no shutdown command. 

Configuring the Physical Interface for the Dialer Interface 

1 Enter interface serial card /port to specify the interface. 

2 Enter encapsulation ppp to set PPP encapsulation. 
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3 Enter media-type {RS232 \ RS422 \ RS449 \ RS530A \ V35 \ X21} for 
the cable your interface connects to. 

The default media-type is RS232. 

4 Enter no shutdown to enable the interface. 

5 Enter ppp max-bad auth number to set the number of retries after 
which the interface resets itself. 

6 Enter dialer pool-member pool-number priority priority to assign the 
interface as a member of the pool that the dialer interface will use. 

Pool-number is a value ranging from 0 to 255 specifying the pool. 
Priority is an optional value ranging from 0 to 255 that you can 
configure to prioritize this pool-member within the pool. 

7 Enable the interface by entering the no shutdown command. 

Configuring the Interface as the Backup Dialer Interface 

1 Enter interface serial card/port to specify the interface to back up. 

2 Enter ip address ip-address mask to specify the IP address and 
subnet mask of the interface. 

3 Enter backup interface dialer number as the backup interface. 

4 Enter backup delay enable-delay disable-delay to set the interval 
between the physical interface going down and the backup being 
enabled, and between the physical interface coming back up and the 
backup being disabled. 

5 Enter backup time-range start-time end-time to set the time of day 
the backup interface should be enabled and disabled. 

6 Enable the interface by entering the no shutdown command. 

The CLI commands shown below are those used to configure the example 
shown in Figure 13. 

Configure interface dialer 0 to use dial pool 5: 

XSR (conf ig) #interf ace dialer 0 

XSR (conf ig-if <D1>) #encapsulation ppp 
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XSR (conf ig-if <D1>) #dialer pool 5 
XSR (conf ig-if <D1>) #no shutdown 

Configure interface dialer 1 to use dial pool 5: 
XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #encapsulation ppp 
XSR (conf ig-if <D1>) #ppp authentication chap pap 
XSR (conf ig-if <D1>) #dialer pool 5 
XSR (conf ig-if <D1>) #no shutdown 

Configure serial port(s) for dial purposes and assign to dial pool 5: 
XSR (conf ig) #interf ace serial 1/2 
XSR (conf ig-if <Sl/2>) #encapsulation ppp 
XSR (conf ig-if <Sl/2>) #media-type v35 
XSR (conf ig-if <Sl/2>) #dialer pool-member 5 
XSR (conf ig-if <Sl/2>) #no shutdown 

Configure the primary serial port 1/0 to use dialer 1 as its backup interface: 
XSR (conf ig) #interf ace serial 1/0 

XSR(config-if<Sl/0>) #ip address 100.100.10.1 255.255.255.0 

XSR (conf ig-if <Sl/0>) #encapsulation ppp 

XSR (conf ig-if <Sl/0>) #backup interface dialerO 

XSR (conf ig-if <Sl/0>) #no shutdown 

Configure the primary serial port 1/1 to use dialer 2 as its backup interface: 
XSR (conf ig) #interf ace serial 1/1 
XSR (conf ig-if <S1/1>) #backup interface dialer 1 
XSR (conf ig-if <S1/1>) #encapsulation ppp 
XSR (conf ig-if <S1/1>) #no shutdown 

Configuring BAP 

The XSR is designed to provide Dial on Demand (DoD) functionality in 
addition to BAP, which is essentially an enhancement of Bandwidth on 
Demand (BoD). The router performs DoD when a dialer map and dialer group 
values are configured as well as multilink PPP. 
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One function central to DoD is the XSR's ability to perform LAN route 
spoofing, a means of maintaining routes in the routing table while keeping 
unused lines physically down. 

The router brings up a line only when it receives a data packet and tears it 
down when idle timeout values are reached. Spoofing on the XSR is 
applicable to the dial out router only. Additional configuration includes 
specifying call/callback request (for BAP configurations) and load threshold 
(BoD) values. 

On the XSR, DoD automatically brings up the first link if the router is the 
caller, and BAP negotiates raising the remaining links as they are needed. 

The following tasks are required to configure BAP: 

□ Set up PRI/BRI physical interfaces 

□ Configure BAP values such as the load threshold and phone numbers 

The following examples configure BAP, DoD, Call Request and Callback 
Request features on connected XSRs. 

Dual XSRs: One Router Using DoD with Call Request 

The following example sets up BAP on connecting XSRs over PRI and BRI 
interfaces with each capable of calling the other. The configurations are 
complimentary except only one XSR will add or remove links. 

XSR1 Configuration 

1 Begin configuring XSR1 by setting up the T1 controller (PRI interface): 

XSRl (config) #controller tl 1/0 

XSR1 (conf ig-controller<Tl-l/0>) #pri-group 

XSRl (conf ig-controller<Tl-l/0>) #isdn bchan- number -order ascending 
XSRl (conf ig-controller<Tl-l/0>) #no shutdown 

XSRl (conf ig- control ler<Tl- 1/ 0>) #dialer pool-member 1 priority 0 

2 Configure BRI interface 2/0 with the basic-nil switch type and two SPIDs: 

XSRl (conf ig) #interf ace bri 2/0 

XSRl (conf ig-if <BRI-2/0>) #isdn switch-type basic-nil 
XSRl (conf ig-if<BRI-2/0>) #isdn spidl 0337250001 
XSRl (conf ig-if<BRI-2/0>) #isdn spid2 0337250101 
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XSRl (conf ig-if <BRI-2/0>) #no shutdown 

XSR1 (conf ig-if <BRI-2/0>) #dialer pool-member 1 priority 0 

3 Configure the Dialer 1 interface with a dialer pool: 

XSRl (conf ig) #interf ace Dialerl 
XSRl (conf ig-if <D1>) #no shutdown 
XSRl (conf ig-if <D1>) #dialer pool 1 
XSRl (conf ig-if <D1>) #encapsulation ppp 

4 Set up BAP on Dialer 1 by specifying the load-threshold (BoD), enabling 
BAP, and configuring XSR1 to initiate the addition of a link. Note that the 
load threshold is very low, ensuring that BAP will be enabled relatively 
quickly when traffic starts to build. 

XSRl (conf ig-if <D1>) #multilink load- threshold 4 
XSRl (conf ig-if <D1>) #ppp multilink bap 
XSRl (conf ig-if <D1>) #ppp bap call request 

5 Complete Dialer 1 configuration by setting the idle timeout and dialer- 
group values for DoD: 

XSRl (conf ig-if <D1>) #dialer idle-timeout 4000 
XSRl (conf ig-if <D1>) #dialer-group 2 

XSRl (conf ig-if <D1>) #ip address 99.99.1.2 255.0.0.0 

6 Configure the dialer list and ACL for DoD: 

XSRl (conf ig-if <D1>) #access-list 102 permit icmp list 102 
XSRl (conf ig-if <D1>) #dialer-list 2 protocol ip list 102 

XSR2 Configuration 

XSR2 is configured to accept incoming calls only. 

1 Begin configuring XSR2 by setting up the T1 controller (PRI interface): 

XSRl (conf ig) #controller tl 1/0 

XSR2 (conf ig-controller<Tl-l/0>) #pri-group 

XSR2 (conf ig-controller<Tl-l/0>) #isdn bchan- number -order ascending 
XSR2 (conf ig-controller<Tl-l/0>) #no shutdown 

XSR2 (conf ig-controller<Tl- l/0>) #dialer pool-member 1 priority 0 

2 Configure BRI interface 2/0 with the basic-nil switch type and two SPIDs: 

XSR2 (conf ig) #interf ace bri 2/0 
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XSR2 (conf ig-if <BRI-2/0>) #isdn switch-type basic-nil 
XSR2 (conf ig- if <BRI -2/ 0>) #isdn spidl 0337250001 
XSR2 (conf ig- if <BRI -2/ 0>) #isdn spid2 0337250101 
XSR2 (conf ig-if <BRI-2/0>) #no shutdown 

XSR2 (conf ig-if <BRI-2/0>) #dialer pool-member 1 priority 0 

3 Configure the Dialer 1 interface with a dialer pool: 

XSR2 (conf ig) #interf ace Dialerl 
XSR2 (conf ig-if <D1>) #no shutdown 
XSR2 (conf ig-if <D1>) #dialer pool 1 
XSR2 (conf ig-if <D1>) #encapsulation ppp 

4 Set up BAP on Dialer 1 by enabling BAP and adding BAP phone numbers 
forXSRYto call. 

XSR2 (conf ig-if <D1>) #ppp multilink bap 
XSR2 (conf ig-if <D1>) #ppp bap number default 3101 
XSR2 (conf ig-if <D1>) #ppp bap number default 3102 
XSR2 (conf ig-if <D1>) #ppp bap number default 3103 
XSR2 (conf ig-if <D1>) #ppp bap number default 3104 
XSR2 (conf ig-if <D1>) #ppp bap number default 3105 
XSR2 (conf ig-if <D1>) #ip address 99.99.1.1 255.0.0.0 

Dual XSRs: BAP Using Call/Callback Request 

The following example sets up BAP between two XSRs, with XSR1 configured 
to perform Dial on Demand (DoD) and request additional links by sending a 
callback request to XSR2, which also is configured with DoD and requests 
additional links with call requests to XSR1. 

XSR1 Configuration 

XSRl (conf ig) #controller el 2/0 

XSR1 (conf ig-controller<Tl-2/0>) #pri-group 

XSRl (conf ig-controller<Tl-2/0>) #no shutdown 

! 

XSRl (conf ig) #interf ace Dialerl 
XSRl (conf ig-if <D1>) #no shutdown 
XSRl (conf ig-if <D1>) #dialer pool 1 
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XSRl (conf ig-if <D1>) #encapsulation ppp 

XSR1 (conf ig-if <D1>) #multilink load- threshold 3 

XSRl (conf ig-if <D1>) #ppp multilink bap 

XSRl (conf ig-if <D1>) #ppp bap number default 3200 

XSRl (conf ig-if <D1>) #ppp bap callback request 

XSRl (conf ig-if <D1>) #dialer-group 2 

XSRl (conf ig-if <D1>) #dialer map ip 10.10.10.2 1300 

XSRl (conf ig-if <D1>) #ip address 10.10.10.1 255.255.255.0 

XSRl (conf ig) #access-list 102 permit icmp any any 8 

XSRl (conf ig) #dialer-list 2 protocol ip list 102 

XSR2 Configuration 

XSR2 (conf ig) #controller el 2/0 

XSR2 (conf ig-controller<Tl-2/0>) #pri-group 

XSR2 (conf ig-controller<Tl-2/0>) #no shutdown 

XSR2 (conf ig-controller<Tl-2/0>) #dial pool-member 1 

XSRl (conf ig) #interf ace Dialerl 

XSRl (conf ig-if <D1>) #no shutdown 

XSRl (conf ig-if <D1>) #dialer pool 1 

XSRl (conf ig-if <D1>) #encapsulation ppp 

XSRl (conf ig-if <D1>) #ppp multilink bap 

XSRl (conf ig-if <D1>) #ppp bap number default 1301 

XSRl (conf ig-if <D1>) #ppp bap number default 1300 

XSRl (conf ig-if <D1>) #ppp bap call request 

XSRl (conf ig-if <D1>) #dialer-group 2 

XSRl (conf ig-if <D1>) #dialer map ip 10.10.10.1 3200 

XSRl (conf ig-if <D1>) #ip address 10.10.10.2 255.255.255.0 

XSRl (conf ig) #access-list 102 permit icmp any any 8 
XSRl (conf ig) #dialer-list 2 protocol ip list 102 

Further description of MLPPP and configuration of its various applications 
on the XSR can be found in "Configuring Dialer Services' 7 on page 135 and 
"Configuring Integrated Services Digital Network (ISDN)" on page 187 in 
this manual, and the XSR CLI Reference Guide. 
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Overview 

Frame Relay is a simple, bit-oriented protocol that offers fast-packet 
switching for wide-area networking. It combines the statistical multiplexing 
and port-sharing features of an X.25 connection with high speed and low 
delay to provide high performance and less overhead. Frame Relay organizes 
data into variable-length, individually addressed units known as frames 
rather than placing them in fixed time slots for delivery over a packet- 
switched network where the data channel is occupied only for the duration of 
the transmission. 

Virtual Circuits 

Frame Relay is based on the concept of the Virtual Circuit (VC) - a two-way, 
always on, software-defined data path between two ports that acts as a 
"private" line in the network. The XSR supports Permanent Virtual Circuits 
(PVCs), multiplexing several PVCs in a single Frame Relay port, which 
reduces the number of physical connections required to link sites. A Frame 
Relay connection can be ordered with multiple PVCs connecting to different 
remote site. Refer to Figure 14 for a typical network topology. 

DLCIs 

The Data Link Connection Identifier (DLCI) is a unique number assigned to a 
PVC end point, essentially, the port to which the destination network is 
attached. DLCIs can perform data "interleaving" from two or more devices 
on a single channel known as statistical multiplexing. Data entering a Frame 
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Relay switch are processed by the DLCI in three ways: frames are checked for 
integrity, their associated DLCI is looked up in the DLCI table, and they are 
relayed to their destination through the port specified in the table. If the 
checks reveal errors or do not find the DLCI in the table, frames are discarded. 

The frame-relay interf ace -die i command maps a DLCI to a specified 
Frame Relay sub-interface. 




Frame Relay 
(Packet Switching Network) 



DLCIs ^ 



Toronto 



Figure 14 Frame Relay Network Topology 

From the perspective of the OSI reference model, Frame Relay is a high- 
performance WAN protocol suite that operates at the physical and data link 
layers (1 and 2). Starting from a source site, variable-length packets are 
switched between the various network segments until the destination is 
reached. 

Devices attached to a Frame Relay WAN fall into two categories: Data 
Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE). 
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DTEs 

A DTE is a network end station, either the ultimate source or destination of 
data through a Frame Relay network. A Frame Relay device can be a router, 
bridge, terminal or PC. For example, the XSR acts as a DTE originating or 
terminating device. 

As a source device, a DTE encapsulates data in a Frame Relay frame and 
transmits. As a destination device, a DTE de-encapsulates Frame Relay data 
(strips the Frame Relay "header" from the packet) leaving only user IP data. 
The frame-relay intf -type dte command assigns the device to the port. 

DCEs 

A DCE is an internetwork switching device located at your service provider's 
premises. DCEs provide network clocking and the switches which actually 
transmit data across the WAN. In most cases, these are packet switches. 

The connection between a DTE device and a DCE device consists of both 
physical- and link-layer components. The physical component defines 
mechanical, electrical, functional, and procedural specifications of the 
connection between the devices while the link-layer component defines the 
protocol that establishes the connection between the DTE and the DCE. 

Frame Relay Features 

The XSR supports the following Frame Relay features: 

□ The router acts as a DTE device in the UNI (User Network Interface) 
interface, supporting Frame Relay PVC connections. DCE 
functionality is not supported. 

□ 10-bit DLCI addressing using a 2-byte DLCI header. 3- and 4-byte 
DLCI headers are not supported. 

□ Rate enforcement (CIR) with automatic rate fallback via 
traffic/ adaptive shaping when the network is congested. 
Automatically restores to normal rates when congestion is removed. 

□ Congestion control by Backward Explicit Congestion Notification 
(BECN). The XSR does not send packets with the BECN bit set. 

□ The three standard LMIs: ILMI (FRF1.1) ANSI Annex D, CCITT 
Annex A. Also supported: Auto LMI detect and None. 
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□ Multi-protocol interconnect over Frame Relay - RFC-2427. Only IP is 
supported. 

□ RFC-2390 Frame Relay Inverse ARP. 

□ Multiple logical interfaces over the same physical Frame Relay port 
(sub-interfaces). 

□ Quality of Service: standard FIFO queuing, or IP QoS on DLCIs. 

□ Max PDU size of 1500 bytes. 

□ Industry-standard CLI and statistics. 

The XSR proscribes the following maximum configuration limits with 
standard memory installed (64 Mbytes): 

□ 30 Frame Relay interfaces or sub-interfaces per node. 

□ 300 DLCIs per node. 

□ 30 Frame Relay map-classes. 

Multi-Protocol Encapsulation 

XSR supports encapsulation of multiple protocols - a flexible way to carry 
many protocols via Frame Relay. This method is useful when it is necessary to 
multiplex/ de-multiplex across one Frame Relay connection, as described by 
RFC-2427, which defines a generic, end-to-end encapsulation mechanism for 
devices to communicate many protocols over a single port. 

Address Resolution 

The XSR supports dynamic resolution via Inverse ARP to map virtual circuits 
(DLCI) to remote protocol addresses, as defined in RFC-2390. 

Dynamic Resolution Using Inverse ARP 

Inverse ARP allows a network node to request a next hop IP address 
corresponding to a given hardware address. Technically, this applies to Frame 
Relay nodes that may have a Data Link Connection Identifier (DLCI), the 
Frame Relay equivalent of a hardware address, associated with an established 
Permanent Virtual Circuit (PVC), but do not know the IP address of the node 
on the other side of the connection. 
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Controlling Congestion in Frame Relay Networks 

While Frame Relay provides dedicated, logical channels throughout the 
network, these channels share physical resources - links and Frame Relay 
switches, for example. When a DLCI is provisioned, the network assigns a 
Committed Information Rate (CIR), Committed burst (Be) and Excess burst 
(Be) values for the virtual circuit. 

Both CIR and Be values are guaranteed under normal conditions. Excess burst 
bandwidth, though, is not guaranteed at all times. You can set the CIR rate on 
the XSR with the frame -relay cir command. 

Frame Relay network design assumes that not all users will need all of their 
provisioned bandwidth all the time, and that any unused excess capacity can 
be borrowed by other customers to send bursts of data exceeding their 
Committed burst rate. In this environment, it is possible for multiple users to 
contend for the same resources at the same time causing congestion. 

If congestion does occur, Frame Relay provides several reactive mechanisms, 
including explicit congestion notifications that inform end stations that 
congestion exists on the network. 

One issue with reactive congestion controls is that congestion has already 
occurred. Although congestion is eventually cleared, frames may be lost and 
response times reduced. This problem can be solved if network traffic is 
limited to avoid congestion in the first place and that is accomplished with 
enforced CIR for a PVC. 

CIR enforcement also prevents a PVC from hogging all the bandwidth on the 
access link - the connection between the access device and the Frame Relay 
switch. Without this feature, one VC can use all the access-link bandwidth 
before Frame Relay congestion techniques even start up. 

Rate Enforcement (CIR) - Traffic Shaping 

Traffic shaping is a high level switch to throttle output traffic to address 
congestion on the network, enabled by the frame- relay traffic -shaping 
command on the XSR. Adaptive shaping is the ability to further reduce CIR to 
alleviate network congestion, enabled by the frame -relay adaptive - 
shaping command on the XSR. 
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CIR is the minimum rate of service that a public Frame Relay provider 
guarantees for a given PVC under normal conditions. Frame Relay provides 
the ability to burst beyond the CIR if bandwidth is available. 

You can transmit traffic at a rate exceeding the CIR using Excess Information 
Rate (EIR), but excess traffic might be discarded in the event of congestion. 
Traffic shaping prevents traffic from being sent in excess of a value such as 
CIR, which considerably reduces the likelihood of network congestion. 
Without this feature, one VC could use all the access-link bandwidth before 
Frame Relay congestion techniques even begin. 

Several other parameters work hand-in-hand with CIR in controlling traffic 
flow. Committed burst (Be) is the maximum number of bits that the network 
attempts to deliver during a given period. 

Be differs from CIR - it is a number, not a rate. CIR is equal to the committed 
burst divided by time interval Tc, expressed in the formula: CIR = Bc/Tc. The 
frame -relay be command sets outgoing committed burst size. 

Excess burst (Be) is the maximum number of bits that you may send in excess 
of Be. Sent on a best-effort basis, these bits will likely be discarded during 
congestion. The frame -relay be command sets outgoing excess burst size. 

Another method of traffic shaping is the use of queues to limit surges that can 
congest a network. Data is buffered and then sent to the network in regulated 
amounts to ensure that traffic will fit within the promised traffic envelope for 
the particular connection. Traffic shaping is also known as metering, shaping, 
and smoothing. 

Forward Explicit Congestion Notification (FECN) 

Forward Explicit Congestion Notification (FECN) sets a bit to inform the DTE 
device receiving the frame that congestion was experienced in the path from 
source to destination. A DTE device receiving frames with the FECN bit set 
can request that higher-level protocols take flow-control action as 
appropriate. 

Receiving a frame with the FECN bit set indicates that the received frame 
experienced congestion en route, and that a method to slow down the peer 
shall be used. The XSR does not act upon receiving a frame with the FECN bit 
set. 
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Backward Explicit Congestion Notification (BECN) 

Backward Explicit Congestion Notification (BECN) sets a bit in frames 
traveling the opposite direction of frames encountering a congested path. A 
DTE device receiving frames with the BECN bit set can request that higher- 
level protocols take flow control action as appropriate. Frames received with 
the BECN bit set indicates that the transmit path is congested. 




Figure 15 Congestion Notification 



Using BECN bits to control the outbound flow of data is known as adaptive 
shaping. This feature is disabled by default on the XSR. To activate the 
feature, you must first enable traffic shaping on the interface. Second, you 
must associate a map class with this interface, sub-interface or DLCI which 
has the adaptive shaping parameter enabled. 

Be aware that unless traffic shaping is enabled, BECN will not operate. 
The following sample configuration shows how to activate BECN support: 

XSR (conf ig) #map-class frame-relay STG 

XSR (conf ig-map-class<STG>) #f rame-relay cir out 64000 

XSR (conf ig-map-class<STG>) # frame -relay be out 8000 

XSR (conf ig-map-class<STG>) #f rame-relay be out 8000 

XSR (conf ig-map-class<STG>) #f rame-relay adaptive -shaping 

XSR (conf ig) #interf ace serial 1/0 
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XSR (conf ig-if <Sl/0>) #no shutdown 

XSR(conf ig-if<Sl/0>) #media-type V35 

XSR (conf ig-if <Sl/0>) #encapsulation f rame-relay 

XSR (conf ig-if <Sl/0>) #f rame-relay lmi-type ansi 

XSR (conf ig-if <Sl/0>) #f rame-relay traffic -shaping 

XSR (conf ig) #interf ace serial 1/0.1 multi-point 

XSR (conf ig-subif <Sl/0 . 1>) #f rame-relay interf ace-dlci 16 

XSR(config-fr-dlci<Sl/0.1-16>) #class STG 

XSR (conf ig-f r-dlci<Sl/0 . 1-16>) #no shutdown 

XSR(config-fr-dlci<Sl/0.1-16>#ip address 210.16.0.1 255.255.0.0 

Under normal circumstances, a DLCI is authorized to transmit a number of 
bits per an interval of time. The number of bits is composed of adding Be and 
Be values (8000, 8000 = 16000 bits). The interval allowed to transmit this 
quantity of bits is based on the formula: Bc/CIR (8000/64000 = 125 
milliseconds). So under normal non-congested conditions, this DLCI should 
transmit up to 16000 bits every 125 milliseconds. 

NOTE 



When adaptive shaping is enabled and BECNs are received, the XSR 
becomes congested and lowers the output rate on the DLCI. Other DLCIs' 
throughput is not affected. 



Upon receiving the first BECN, the Be amount is removed from the equation. 
Now the DLCI can transmit 8000 bits every 125 milliseconds. If no more 
BECNs are received within 3 seconds, 1/2 of the Be amount is added back 
each 3-second interval until the Be is fully restored. 

Upon receiving additional BECNs within three seconds, the CIR is reduced 
by 7/ 8ths of the current CIR. Every three seconds that BECNs are received, 
the CIR will be reduced by an additional 7/ 8ths of the new CIR value, until 
the new CIR value is 1/2 of the original CIR value. One-half of the original 
CIR is called the minimum CIR, a non-configurable parameter. 

Once BECNs stop being received, the current CIR begins to recover the 
original CIR at a rate of l/16th of the original CIR every 3 seconds: l/16th 
facilitates a graceful, slower recovery in the hope of preventing network 
thrashing when all devices start recovering from congestion. After CIR is 
fully recovered, Be is reintroduced at a rate of 1/2 of Be every 3 seconds. 
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Link Management Information (LMI) 

A Frame Relay switch communicates with another Frame Relay switch or an 
attached Frame Relay DTE device (e.g., the XSR) about the status of the PVC 
connections through Link Management Information protocol (LMI). 

LMI monitors the status of the connection and provides the following data: 

□ Active /inactive interface - known as a keep alive or heartbeat signal. 

□ The valid DLCIs defined for that interface. 

□ The status of each DLCI (either New, Activate or Delete). 
Three versions of the LMI specification as described below: 
Protocol Specification 

ILMI, (OGOF) Frame Relay Forum Implementation Agreement (IA) 
FRF.l superseded by FRF. 1.1 

Annex D (ANSI) ANSI T1.617 

Annex A (Q933a) ITU Q.933 

The protocol defined for the LMI provides a status inquiry message which the 
the XSR can send, either as a keep alive message to inform the network that the 
connection to the router is still up, or as a request for a report on the status of 
the PVCs on that port. The network then responds with a status message, 
either in the form of a keep alive response or full report on the PVCs. 

An optional status update message lets the network unilaterally report a PVC 
status change. An LMI status query provides for one-way querying and one- 
way response only, meaning that only the XSR can send a status inquiry 
message, and only the network can respond with a status message. Using 
status inquiries in this manner renders both sides of the interface unable to 
provide the same commands and responses. 

In contrast to the ILMI (which uses DLCI 1023), Annex D reserves DLCI 0 for 
PVC status signaling. The current requirement in Annex A signaling is similar 
to Annex D and also uses DLCI 0. 
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^ NOTE 

Be sure the same version of the management protocol resides at each end 
of the Frame Relay link except for Auto. 



Each version includes a slightly different use of the management protocol. 
The XSR implements all three LMIs behaving as a DTE as well as auto, none 
and default options using the frame -relay lmi-type command. Auto is the 
fastest LMI type. 

Sub-interface Support 

The XSR implements Frame Relay as a multi-access media in which one 
interface to the network - the physical connection - has one or more 
destinations, namely, virtual connections. All virtual connections are grouped 
with their corresponding physical connection. For this purpose, the XSR 
groups one or more PVCs under separate sub-interfaces, which in turn are 
associated with a single physical interface. 

The frame -relay interface -die i command assigns a DLCI to a sub- 
interface. The class command assigns a map class to a DLCI on a sub- 
interface. 

User Interfaces 

This section describes user interface functions including Frame Relay related 
configuration, statistics and alarms. 

All CLI commands are interpreted immediately by the XSR and become part 
of the on-line running configuration. If a parameter in a Frame Relay map is 
changed, the change is reflected automatically by Frame Relay devices which 
reference this map. But new configuration changes are not saved into the 
startup configuration file until you enter the copy running config startup 
conf ig command to copy the running configuration into the startup 
configuration file within Flash memory. 
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Displaying Statistics 



Map-Class Configuration 

The Map Class configures a common profile (characteristics) that can be applied 
to PVCs, eliminating the need to configure parameters on all individual PVCs. 
The map -class f r ame - re 1 ay command configures a Frame Relay map class . 

Show Running Configuration 

The show running-configuration command displays the running 
configuration on the screen. 



NOTE 



Only those parameters different than default values are displayed. 



Displaying Statistics 

The following show commands display Frame Relay statistics: 

□ show frame -relay lmi - displays global or interface LMI counters 

□ show frame-relay map - displays DLCIs and remote nodes' IP 
addresses discovered by Inverse ARP. 

□ show frame-relay traff ic - displays Inverse ARP traffic statistics. 

□ show frame -relay pvc - displays global or per interface, sub- 
interface or DLCI data 

Reports and Alarms 

The Frame Relay-related alarms are described in Appendix A: 
"Alarms /Events and System Limits " on page 355. 

Clear Statistics 

When it becomes necessary, you can strip the Inverse ARP Table and other 
tables of Frame Relay statistics with the clear frame-relay inarp and 
clear frame-relay counter commands. The clear frame-relay inarp 
command deletes particular or global Frame Relay port data and the clear 
frame -relay counter command deletes specific or global DLCI or Frame 
Relay port data. 
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Interconnecting via Frame Relay Network 

The following typical application uses Frame Relay to link remote branches to 
the corporate network at the central sites via a Frame Relay network. 



Minneapolis 
Houston 




Frame Relay switch combines DLCIs from various 
remote branch sites at 56 kbps into a single high 
speed Frame Relay T1 interface with a large 
number of DLCIs at the central sites. 




New York 



Frame Relay 
Network 




Toronto 

Boston 

Branch Sites 

□Medium speed FR links (32 - 128 kbps) 

□ 1-4 DLCIs linking one or more central sites on 
different subnets 

□All DLCIs share characteristics (CIR, Be, Be) 

□IP traffic requires traffic prioritization, 
bandwidth allocation 

□Backup FR link using dial-up (ISDN or dialed 
modem) PPP connections or encrypted tunnel 
via Internet 



Central Sites 



□High speed FR link (clear channel Tl/El 
links, may be channelized or fractional T3) 

□Many DLCIs per link 

□May use sub-interfaces to connect to 
multiple subnets, each spanning multiple 
remote sites 

□Link to many remote sites, may use FR 
QoS templates to address different remote 
sites 

□IP traffic requires prioritization, 
bandwidth allocation 

□Backup solutions: separate central sites 
via dial- in modem pools or ISDN 
BRI/PRI with PPP, or via encrypted 
tunnels over the Internet 



Figure 16 Branch/Central Frame Relay Topology 
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Configuring Frame Relay 

Multi-point to Point-to-Point Example 

The following example configures the XSR in Austin to connect with XSRs in 
Boston, Charlotte, and Denver using Frame Relay, as shown in Figure 17. 

This example is not designed for OSPF networks since the nodes have 
mixed configurations. OSPF requires sub-interfaces to be set identically: 
either all point-to-point or all multipoint to multipoint. 



Austin 




xsr Boston 


multipoint subnet 1 




10.10.10.4 


(10.10.10.1) to remote sites 




j\ point to point 


Boston (did: 16, CIR: 64Kbps 




dlci: 16 


Charlotte (dlci: 17, CIR: 128Kbps) 




CIR: 64Kbps 


point to point subnet 2 






(10.10.11.1) to Denver 






(DLCI: 20, CIR: 64Kbps) 


Frame Relay 
Network 


XSR 


^^^^ 




Charlotte 






10.10.10.3 
XSR point to point 




Denver 




10.10.11.2 


dlci: 16 




point to point 


J> CIR: 128Kbps 




dlci: 16 






CIR: 64Kbps 





Figure 17 Frame Relay Multipoint to Point-to-Point Topology 



The following CLI commands enable the sample multipoint to point-to-point 
configuration pictured above. At the Austin site, a multipoint network with a 64 
Kbps PVC is configured to Boston and 128 Kbps PVC is configured to Charlotte. 
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A point-to-point network with a 64 Kbps connection is also configured from 
Austin to Denver. Boston, Denver, and Charlotte each are configured with 
point-to-point networks with 64 Kbps, 128 Kbps, and 64 Kbps PVCs, 
respectively. 

On the Austin XSR, enter: 

XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig-if <Sl/0>) #encapsulation f rame- relay 

XSR (conf ig-if <Sl/0>) #media-type v35 

XSR (conf ig-if <Sl/0>) # frame -relay traffic -shaping 

XSR (conf ig-if <Sl/0>) #no shutdown 

XSR (conf ig) #interf ace serial 1/0.1 multipoint 

XSR(config-subif<Sl/0.1>)#ip address 10.10.10.1 255.255.255.0 

XSR (conf ig-subif <S1/ 0 . 1># frame -relay interf ace-dlci 16 

XSR (conf ig-f r-dlci<Sl/0 . l-16>#class slowlink 

XSR (conf ig-subif <Sl/0 . l>#f rame-relay interf ace-dlci 17 

XSR (conf ig-f r-dlci<Sl/0 . l-17>#class fastlink 

XSR (conf ig) #interf ace serial 1/0.2 point-to-point 

XSR(config-subif<Sl/0.2>)#ip address 10.10.11.1 255.255.255.0 

XSR (conf ig-subif <Sl/0 . 2>#f rame-relay interf ace-dlci 20 

XSR (conf ig-f r-dlci<Sl/0 .2-2 0>#class slowlink 

XSR (conf ig) #map-class frame-relay slowlink 

XSR (conf ig-map-class<slowlink>) #f rame-relay cir out 64000 

XSR (conf ig) #map-class frame-relay fastlink 

XSR (conf ig-map-class<f astlink>) #f rame-relay cir out 128000 

On the Boston XSR, enter: 

XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig-if <Sl/0>) #encapsulation f rame-relay 

XSR (conf ig-if <Sl/0>) #f rame-relay traffic -shaping 

XSR (conf ig-if <Sl/0>) #no shutdown 

XSR (conf ig-if <Sl/0>) #media-type v35 

XSR (conf ig) #interf ace serial 1/0.1 point-to-point 

XSR (conf ig-subif <Sl/0.1>#ip address 10.10.10.4 255.255.255.0 

XSR (conf ig-subif <Sl/0 . l>#f rame-relay interf ace-dlci 16 

XSR (conf ig-f r-dlci<Sl/0 . l-16>#class slowlink 

XSR (conf ig-subif <Sl/0 . 1>) #map-class frame-relay slowlink 

XSR (conf ig-map-class<slowlink>) #f rame-relay cir out 64000 
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On the Charlotte XSR, enter: 

XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig-if <Sl/0>) #encapsulation f rame- relay 

XSR (conf ig-if <Sl/0>) #f rame -relay traffic -shaping 

XSR (conf ig-if <Sl/0>) #media-type v35 

XSR (conf ig-if <Sl/0>) #no shutdown 

XSR (conf ig) #interf ace serial 1/0.1 point-to-point 

XSR (conf ig-subif<Sl/0.1>)#ip address 10.10.10.3 255.255.255.0 

XSR (conf ig- subif <S1/ 0 . 1>) # frame -relay interf ace-dlci 16 

XSR (conf ig-fr-dlci<Sl/0 . 1-16>) #class fastlink 

XSR (conf ig-fr-dlci<Sl/0 . 1-16>) #no shutdown 

XSR (conf ig- subif <S1/ 0 . 1>) #map- class frame-relay fastlink 

XSR (conf ig-map-class<f astlink>) #f rame-relay cir out 128000 

On the Denver XSR, enter: 

XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig-if <Sl/0>) #encapsulation f rame-relay 

XSR (conf ig-if <Sl/0>) #f rame-relay traffic -shaping 

XSR (conf ig-if <Sl/0>) #media-type v35 

XSR (conf ig-if <Sl/0>) #no shutdown 

XSR (conf ig) #interf ace serial 1/0.1 point-to-point 

XSR (conf ig-subif<Sl/0.1>#ip address 10.10.11.2 255.255.255.0 

XSR (conf ig-subif <Sl/0 . l>#f rame-relay interf ace-dlci 16 

XSR (conf ig-f r-dlci<Sl/0 . l-16>#class slowlink 

XSR (conf ig-f r-dlci<Sl/0 . l-16>#no shutdown 

XSR (conf ig-subif <Sl/0 . 1>) #map-class frame-relay slowlink 

XSR (conf ig-map-class<slowlink>) #f rame-relay cir out 64000 
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This chapter details information about the XSR's suite of dialer functionality: 



□ 


Dial 


□ 


Ethernet Failover 


□ 


Backup Dialer 


□ 


Dial on Demand (DoD) 


□ 


Bandwidth on Demand (BoD) 


□ 


Multilink PPP (MLPPP) 



Overview of Dial Services 

Dial Services provide network connections across the Public Switched 
Telephone Network (PSTN). Networks are typically interconnected using 
dedicated lines for Wide- Area Network (WAN) connections. Dial Services can 
use modems, Integrated Service Data Network (ISDN) terminal adapters 
(TAs), or integrated ISDN capabilities to establish low-volume, periodic 
network connections over public circuit-switched networks. 

Dial Services are a cost-saving alternative to a leased line connection between 
two peers and they can be implemented for different types of media for both 
inbound and outbound connections. 

Dial Services Features 

The XSR supports the following dialer features: 

□ Asynchronous serial service through an external modem 

□ Synchronous serial 
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□ Addressing using numbered or unnumbered interfaces 

□ Outbound connections 

□ Time of day feature 

□ PPP encapsulation 

□ CHAP, MS-CHAP and PAP authentication and security 

□ Callback 



Modem Modem 




Figure 18 Typical Dial Services Interconnection 



Asynchronous and Synchronous Support 

Synchronous and asynchronous interfaces can be configured for dialed 
connections to one or more destination networks. When requested, the 
XSR uses dialing commands to send the phone number of the destination 
network to a modem. The modem then dials the destination modem and 
establishes a connection. Refer to Figure 18. 

Calls can be placed using the following methods: 

□ AT commands on asynchronous ports 

□ V.25bis over synchronous interfaces 

□ DTR dialing for synchronous interfaces 
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AT Commands on Asynchronous Ports 

On asynchronous ports, AT commands are used to establish and clear the call. 
Refer to your modem documentation for a list of supported commands and 
options. The modem should be configured to drive Data Carrier Detect and 
Clear To Send CCITT V.24 signals and accept input of the Data Terminal 
Ready signal set by the XSR. 

V.25bis over Synchronous Interfaces 

Dial services also support connections from the synchronous serial interface 
to any modem that supports V.25bis. V.25bis supports two modes of 
establishing or receiving calls: direct call and addressed call. Dial services 
support connections using the addressed call mode and synchronous, bit- 
oriented operation. The addressed call mode allows control signals and 
commands to be sent over the modem interface to set up and terminate calls. 

Devices used for dialing out must support certain hardware signals in 
addition to V.25bis. When the XSR drops DTR, the device must disconnect 
any calls that are currently connected. When the device connects to the 
remote end, Data Carrier Detect (DCD) must be automatically asserted. For 
many V.25bis devices, raised DCD requires a special cable to crossover DCD 
and Data Set Ready (DSR) signals. 

Table 8 lists V.25bis options. By default, the synchronous port will use V25bis. 
The functions of these options are nation-specific, and they may have 
different implementations. Refer to your modem documentation for a list of 
supported commands and options. 

Table 8 ITU-T V.25bis Options 



Option 


Description 




Wait tone 


< 


Pause 




Separator 3 - national use 


> 


Separator 4 - national use 


P 


Dialing to be continued in pulse mode - optional parameter 
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Table 8 ITU-T V.25bis Options (Continued) 



Option 


Description 


T 


Dialing to be continued in DTMF mode - optional parameter 


& 


Flash - optional parameter 



DTR Dialing for Synchronous Interfaces 

Dialer interfaces also support connections from synchronous serial lines 
through non-V.25bis modems. Routers connected by non-V.25bis modems use 
data terminal ready (DTR) signaling only, which can be configured in the 
dialer interface by issuing the dialer dtr command in Interface mode. 
When using dialer dtr, the dial string is stored in the external device and 
need not be passed to it. 

Time of Day feature 

A time of day feature can be configured when you use a dialer interface as a 
dialed backup line for a primary leased line. When configuring the dialed 
backup line on the primary interface you can issue the time -range command 
to connect and disconnect the dial line during the day regardless of traffic on 
the line or whether the primary line is still down. 

Typical Use for Dial Services 

Dial services provide WAN connectivity on an economical, as-needed basis, 
either as a primary link or as backup for a non-dial serial link. Employing dial 
backup involves setting up a secondary serial interface as a backup to a 
primary serial interface. Dial services are employed solely for dial backup 
purposes, as of this release. 

Ethernet Backup 

Failover support is available on FastEthernet/ GigabitEthernet interfaces or 
sub-interfaces where it is especially beneficial for PPPoE (DSL) redundancy. 
The backup interface dialer command turns failover "on" while the 
backup time -range and backup delay commands configure intervals to 
keep the port up or delay bringing it up. See "Configuration for Ethernet 
Failover" on page 186 for an example. 
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Implementing Dial Services 

Dial services are provided by dialer interfaces, which are defined as any 
XSR interface capable of placing or receiving a call. You can implement Dial 
Services by creating a dialer profile. 

Refer to Figure 19 for a network perspective and Figure 20 for a logical view 
of Dial Services. 





10.1.1.2/24 



Figure 19 - Dial Services - Network View 



Figure 19 illustrates a sample Dialer Profile which defines interface dialers in 
five corporate locations served by the XSR. 
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Dialer Profiles 

Dialer profiles are comprised of virtual and physical interfaces which can be 
bound together dynamically on a per-call basis. Dialer profiles can also be 
configured as physical interfaces separate from the virtual configuration 
required to make a connection. 

This flexibility permits different dialer profiles to share XSR Serial interfaces. 
Dialer profiles are efficient when physical resources number less than users 
because a pool of resources can draw on the resources in the pool based on 
typical use. Be aware that all calls going to or from the same destination 
subnetwork use the same dialer profile. 

A dialer profile consists of the following elements: 

□ Dialer interface is a virtual WAN interface you can configure with data 
that defines communications with destination subnetworks. The 
dialer interface is not constantly connected to a remote device, but 
dials the remote device whenever a connection is needed. To dial up 
at the appropriate time requires configuring a dialer profile. It is 
configured with the interface dialer command. 

□ Dialer map class defines all line characteristics of calls to the 
destination including the interval to wait for a dial signal. It is 
specified with the map class dialer command. 

□ IP address identifies the local side of the connection. It is configured 
with the ip address command. 

□ Dialer strings are phone numbers used to reach a destination. They are 
set with the dialer string command. 

□ Dialer pool is a virtual group of physical interfaces used to reach a 
destination. Interfaces in a dialer pool are weighted by priority. It is 
configured with the dialer pool command. 

Dialer Interface 

A dialer interface, which is a group of settings used by the XSR to connect to a 
remote network, can include multiple dial strings. Each dial string, in turn, 
can be associated with its own map class which defines all the characteristics 
for any call to the specified dial string. Refer to dialer profiles of interface 
dialer 0 which are illustrated in Figure 22 and Figure 23. 
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Dialer Strings 

Setting dialer strings is straightforward but their configuration is very 
flexible. You can specify multiple dialer strings for the same dialer interface 
and each dialer string can be associated with a different dialer map class. 

Dialer Pool 

Each dialer interface uses one group of physical interfaces called a dialer pool. 
The physical interfaces in a dialer pool are called into use based on a priority 
value for selection by the XSR. Again, Serial interfaces can belong to multiple 
dialer pools, allowing a small number of resources to service a large number 
of users. The disadvantage of this method is that all resources may be in use 
when a user tries to access them. 

Addressing Dialer Resources 

There are two ways of setting up addressing on dialer resources, as follows. 

□ Applying a Subnet to the Dialer Cloud - Each site linked to the dialer 
cloud receives a unique node address on a shared subnet for use on 
its dialer interface. This method is similar to numbering a LAN or 
multipoint WAN and simplifies the addressing scheme and creating 
static routes. 

□ Using Unnumbered Interfaces - Similar to using unnumbered 
addressing on leased line point-to-point interfaces, the address of 
another interface on the XSR is borrowed for use on the dialer 
interface. Unnumbered addressing takes advantage of the fact that 
there are only two devices on the point-to-point link. 

The routing table points to an interface (the dialer interface) and a next-hop 
address. When building static routes for unnumbered interfaces the XSR must 
be configured with the interface that finds the next-hop out. 

Configuring Encapsulation 

When a clear data link is established between two peers, traffic must be 
encapsulated and framed for transport across the Dialer media. 
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PPP is the encapsulation method of choice for Dialer Services because it 
supports multiple protocols and is used for synchronous or asynchronous 
connections. Also, PPP performs address negotiation and authentication and 
is interoperable with different vendors. 

ISDN Callback 

ISDN callback funtionality, also known as dial-back, is a Dial on Demand 
application to handle ISDN call charge billing. The benefit of this feature is, if 
a caller contacts the XSR, the router will try to call back a pre-configured 
number, and in the process reverse the associated charge. A maximum of 32 
caller numbers can be set per Dialer port. 

ISDN callback is supported for PPP or Multilink PPP traffic and can be 
applied in a backup scenario if the retry number is set to 1. 

Configured with the dialer caller <number> callback command, the 
functionality employs caller ID screening with ISDN callback to accept calls 
from a specified phone number. The XSR matches phone numbers starting 
with the last digit. 

Typically the ISDN switch does not provide the complete calling number, 
only the local number (four to seven of the least significant digits). 

NOTE 

If the ISDN switch does not provide the calling number, callback will fail. 



Callback can be configured in point-to-point or point-to-multipoint 
applications with one or multiple neighbors. A neighbor in this context is 
considered one hop away from the XSR. 

Refer to "Configuring ISDN Callback" on page 148 for configuration 
examples. 
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16.1.2.0/24 



IP 



10.1.1.1/24 



Interface DialerO 



Map class 



Dialer poolO 



20.1.1.1/24 



Interface Dialerl 



Map class 



Dialer pooh 



SerialO SeriaM 



Serial2 



Serial 3 



Serial 4 




5.1.1.1/24 



Interface Dialer2 



Dialer pool2 



Serial 5 



20.1.1.2/24 




Serial 7 



Serial 8 



5.1.1.3/24 



Figure 20 Logical View of Dialer Profiles 



Figure 20 illustrates how Interface Dialers interact with Map Classes, Dialer 
Pools, Serial interfaces and three corporate sites served by the XSR. The 
squares with darkened backgrounds are Dialer Profiles. Note how Serial 
interfaces 0-4 and Boston and Hollywood are served by two Dialer Profiles. 
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Network 



10.1.1.1/8 



20.2.2.2/24 



Interface dialer 0 

ip address 10.1.1.1 255.0.0.0 

encapsulation ppp 

dialer string 4161234456 class Toronto 
dialer string 9872312345 class Andover 
dialer pool 6 





map class dialer Toronto 
i wait for carrier 20 



Dialer Pool 6 



Serial 1/1 

dialer pool member 6 priority 200 



Serial 1/2 

dialer pool member 6 priority 140 



30.3.3.3/24 



Dialer Interface 2 



map class dialer Andover 
, wait for carrier 30 



Vnnap class dialer NY 
I wait for carrier 50 



Dialer Pool 9 



Serial 1/3 



Dialer Pool 3 



Serial 2/0 



Serial 2/1 



Serial 2/2 



Serial 1/0 



Serial 2/2 is 
shared by Dialer 
Pools 3 and 9 



Figure 21 Sample Dialer Topology 

Figure 21 illustrates three Dialer Interfaces with three associated Dialer Pools. 
Dialer Pool 6 supports two Serial interfaces of different priority // weighting ,/ . 
Dialer Pools 3 and 9 support three Serial interfaces with one interface - Serial 
2/2 - shared between them. 
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Network 



10.1.1.1/8 



Interface dialer 0 

ip address 10.1.1.1 255.0.0.0 

encapsulation ppp 

dialer string 4161234456 class Toronto 
dialer string 9872312345 class Andover 
dialer pool 6 



map class dialer Toronto 
wait for carrier 20 



Dialer Pool 6 
contains two ports: 
Serial 1/1 and Serial 1/2 
Serial 1/1 is preferred 
(has a higher priority) 



Serial 1/1 

dialer pool member 6 priority 200 



Serial 1/2 

dialer pool member 6 priority 140 



Dialer profile for destination 
4161234456 uses the map 
class Toronto and one port 
belonging to pool 6 




Figure 22 Dialer Profile of Destination (416) 123-4456 



As illustrated in Figure 22 and Figure 23, Toronto and Andover Dialer Profiles 
share similar parameters except phone numbers and values specifying the 
interval to wait for a dial signal. 
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Network 



10.1.1.1/8 



Interface dialer 0 

ip address 10.1.1.1 255.0.0.0 

encapsulation ppp 

dialer string 4161234456 class Toronto 
dialer string 9872312345 class Andover 
dialer pool 6 



map class dialer Andover 
wait for carrier 30 



Dialer Pool 6 
contains two ports: 
Serial 1/1 and Serial 1/2 
Serial 1/1 is preferred 
(has a higher priority) 



Serial 1/1 

dialer pool member 6 priority 200 



Serial 1/2 

dialer pool member 6 priority 140 



Dialer profile for destination 
9872312345 uses the map 
class Andover and one port 
belonging to pool 6 




Figure 23 Dialer Profile of Destination (987) 231-2345 



Configuring the Dialer Interface 

The following tasks need to be performed to configure a dialer profile: 

□ Create and configure the dialer interface 

□ Configure a map class (optional but distinguishes dialer profiles) 

□ Configure a physical interface for the dialer interface 
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Creating and Configuring the Dialer Interface 

1 Enter interface dialer number to create the dialer interface. 

The number range is 0 to 255. 

2 Enter encapsulation ppp to enable PPP encapsulation. 

3 Enter dialer pool number to specify the dialer pool. 

The number range is 0 to 255. 

4 Enter dialer string <dialstring> class <classname> to specify the 
remote destination string to be used. 

The string is normally a 10-digit telephone number. 
Configuring the Map Class 

1 Enter map-class dialer classname to create a map-class identifier. 

This value must match the classname value you specified in the 
dialer string command. 

2 Enter dialer wait-for-carrier-time seconds to set the interval the 
local modem waits to answer the call. 

Configuring the Physical Interface for the Dialer Interface 

1 Enter interface serial card/port to specify the interface. 

2 Enter encapsulation ppp to set PPP encapsulation. 

3 Enter dialer pool-member number priority <priority> to assign the 
interface as a member of the pool that the dialer interface will use. 

Priority is an optional value you can set to prioritize this pool- 
member in the pool ranging from 0 - 255. The number range is 0 - 255. 

Sample Dialer Configuration 

The CLI commands listed below are those used to configure dialer interface 0 
in Figure 21. 

Configure interface dialer 0 with two dial strings and map classes for each: 
XSR (conf ig) #interf ace dialer 0 
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XSR(config-if<DO>) #ip address 10.1.1.1 255.0.0.0 
XSR (conf ig-if <D0>) #encapsulation ppp 
XSR (conf ig-if <D0>) #dialer pool 6 

XSR (conf ig-if <D0>) #dialer string 4161234456 class toronto 
XSR (conf ig-if <D0>) #dialer string 9872312345 class andover 
XSR (conf ig-if <D0>) #no shutdown 

Configure a map-class named Toronto with a 20-second wait for the dial tone: 
XSR (conf ig) #map class dialer toronto 

XSR (conf ig-map-class) #dialer wait- f or-carrier- time 20 

Configure a map-class named Andover with a 30-second wait for the daily 
tone: 

XSR (conf ig) #map class dialer andover 

XSR (conf ig-map-class) #dialer wait- f or-carrier- time 30 

Configure a backup link for dial purposes with priority 200: 

XSR (conf ig) #interf ace serial 1/1 

XSR (conf ig-if <S1/1>) #dialer pool 6 priority 200 

XSR (conf ig-if <S1/1>) #no shutdown 

Configure a backup link for dial purposes with priority 140: 

XSR (conf ig) #interf ace serial 1/2 

XSR (conf ig-if <Sl/2>) #dialer pool 6 priority 140 

XSR (conf ig-if <Sl/2>) #no shutdown 

Configuring ISDN Callback 

The following CLI commands configure point-to-point and point-to- 
multipoint applications with single or multiple neighbors. 

Point-to-Point with Matched Calling/Called Numbers 

The following commands configure the called XSR with matched calling and 
called phone numbers: 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #dialer caller 921 callback 

XSR (conf ig-if <D1>) #dialer string 6032217921 

XSR (conf ig-if <D1>) #encapsulation ppp 



148 



XSR User's Guide 



Chapter 8 

Configuring Dialer Services 



Implementing Dial Services 



XSR(config-if<Dl>) #ip address 10.10.10.1 255.255.255.0 
XSR (conf ig-if <D1>) #no shutdown 

Point-to-Point with Different Calling/Called Numbers 

The following commands configure the called XSR with different calling and 
called phone numbers: 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #dialer caller 921 callback 

XSR (conf ig-if <D1>) #dialer string 6783234451 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR(config-if<Dl>) #ip address 10.10.10.1 255.255.255.0 
XSR (conf ig-if <D1>) #no shutdown 

Point-to-Multipoint with One Neighbor 

The following commands configure the called XSR with a callback number 
that may or may not differ from the dial out number. Note that a dialer map 
must be added to specify the particular number to be accepted. 

XSR (conf ig) #interf ace dialerl 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #dialer caller 921 callback 

XSR (conf ig-if <D1>) #dialer idle- timer 0 

XSR (conf ig-if <D1>) #dialer map ip 10.10.10.2 9053617921 
XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 10.10.10.1 255.255.255.0 
XSR (conf ig-if <D1>) #no shutdown 

Point-to-Multipoint with Multiple Neighbors 

The following commands configure the called XSR with a callback number 
that must match the dial out number. The first number specified, 9053617921, 
will be used for callback. 

XSR (conf ig) #interf ace dialerl 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #dialer caller 921 callback 

XSR (conf ig-if <D1>) #dialer idle- timer 0 

XSR (conf ig-if <D1>) #dialer map ip 10.10.10.2 9053617921 
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XSR (conf ig 
XSR (conf ig 
XSR (conf ig 
XSR (conf ig 



if <D1>) #dialer map ip 
if <D1>) #encapsulation 
if<Dl>)#ip address 10 
if<Dl>)#no shutdown 



PPP 



10.10.10.3 9053617363 



10.10.1 255.255.255.0 



Overview of Dial 



Backup 



The dialed backup feature provides a backup link over a dial line. The backup 
link is brought up when failure occurs in a primary link, and is brought down 
when the primary link is restored. 

Dial Backup Features 

□ User controllable delay when the link is activated for backup, and 
when the link is deactivated, that is, brought down. 

□ Dial backup is activated when the XSR detects link failure. 



Dial backup may not be activated if the XSR's link at local site is up and a 
remote site's link is down. 



The XSR distinguishes one type of Link Failure: 

□ When configured, a backup link will be activated on detection of 
primary link failure. 



The following sequence of events occurs when a primary link fails and a 
backup line fails: 

1 A Primary Link fails. 

2 A link failure is detected. This link is configured for backup, and is 
monitored. 

3 The Backup function is notified about link failure. 




NOTE 



Sequence of Backup Events 
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4 With the interface down, all routes reachable through that interface 
are removed from the routing table. 

5 Backup function invokes the dialer to activate the configured (dial) 
backup interface. 

Activating the backup link can be delayed, if configured as such. 

6 Backup link is up. 

7 Backup link is activated. 

8 Backup link is up, triggering the next action. 

9 Static Backup route configured - the routing process searches its 
configured Static Routing entries and installs the routes that can be 
reached through the backup interface. 

10 Dynamic route - the routing protocol (RIP) learns of new available 
routes through the backup (dialer) interface and adds them to the IP 
Routing and Forwarding Table. 

11 Data starts passing over the backup link. 

When the primary link is re-established the backup function will 
notify the Dialer to bring down the dialer interface (bringing the 
dialed line down). 
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Link Failure Backup Example 

Figure 24 illustrates a local link failure and the dial backup process. 




Central Site 



Figure 24 Backup Link Failure Example 

Configuring a Dialed Backup Line 

The following tasks must be performed to configure a dialed backup line: 

□ Configure the dialer interface 

□ Configure a physical interface to function as backup 

□ Configure primary interfaces to use a backup interface 

Configuring the Dialer Interface 

Perform the following steps to configure the dialer interface: 

1 Enter interface dialer number to create the dialer interface. 

2 Enter encapsulation ppp to enable PPP encapsulation. 

3 Enter dialer pool number to specify the dialer pool. 
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Configuring the Physical Interface for the Dialer Interface 

Perform the following steps to set up the physical port for the dialer interface: 

1 Enter interface serial card I port to specify the interface. 

2 Enter encapsulation ppp to set PPP encapsulation. 

3 Enter dialer pool-member pool-number priority priority \o assign the 
interface as a member of the pool that the dialer interface will use. 

Priority is an optional value you can configure to prioritize this pool- 
member within the pool. 

Configuring Interface as the Backup Dialer Interface 

Perform the following steps to configure the port for the dialer backup 
interface: 

1 Enter interface serial card/port to specify the interface to back up. 

2 Enter ip address ip-address mask to specify the IP address and 
mask of the interface. 

3 Enter backup interface dialer number as the backup interface. 

4 Enter backup delay enable-delay disable-delay to set the interval 
between the physical interface going down and the backup being 
enabled, and between the physical interface coming back up and the 
backup being disabled. 

5 Enter backup time-range start-time end-time to set the time of day 
the backup interface should be enabled and disabled. 

The CLI commands shown below are those used to configure the example 
shown in Figure 24. 

Create interface dialer 1 to use dialer pool 6: 

XSR (conf ig) #interf ace dialerl 
XSR (conf ig-if <D1>) #encapsulation ppp 
XSR (conf ig-if<Dl>) #dialer pool 6 
XSR (conf ig-if <D1>) #no shutdown 

Configure backup serial port for dialing purposes: 
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XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig-if <Sl/0) #dialer pool-member 6 

XSR (conf ig-if<Sl/0) #no shutdown 

Configure primary serial port to have interface dialer 1 as its backup interface: 

XSR (conf ig) #interf ace serial 1/1 

XSR (conf ig-if <S1/1) #backup interface dialerl 

XSR (conf ig-if <S1/1) #backup delay 5 10 

XSR (conf ig-if <S1/1) #backup time-range 10:00 22:55 

XSR (conf ig-if <S1/1) #no shutdown 

The backup time -range command specifies the time the backup dial line 
should be up. In the above example the parameters are 10:00 and 22:55, 
meaning that at 10:00 the backup line should be activated and at 22:55 the 
backup line should be deactivated. Enabling and disabling the backup 
interface takes place regardless of the traffic on the link when using the 
backup time -range command. 

Sample Configuration 

Figure 25 shows an example of two dialer interfaces used to back up two 
separate serial lines using only one dial out line (serial interface 1). 
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Configuring a Dialed Backup Line 




XSR 
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Serial Interface 
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Interface 2 



Serial Interface 
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Backup Dialer 
Interface 1 




Leased line 



Figure 25 Backup Dial Example 
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The CLI commands shown below are those used to configure the example 
shown in Figure 25: 

Configure interface dialer 1 to use dial pool 5: 

XSR (conf ig) #interf ace dialerl 
XSR (conf ig-if <D1>) #encapsulation ppp 
XSR (conf ig-if<Dl>) #dialer pool 5 
XSR (conf ig-if <D1>) #no shutdown 

Configure interface dialer 2 to use dial pool 5: 

XSR (conf ig) #interf ace dialer2 
XSR (conf ig-if <D2>) #encapsulation ppp 
XSR (conf ig-if <D2>) #dialer pool 5 
XSR (conf ig-if <D2>) #no shutdown 

Configure backup serial port for dial purposes to belong to dial pool 5: 

XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig-if <Sl/0>) #dialer pool-member 5 

XSR (conf ig-if <Sl/0>) #no shutdown 

Configure primary serial port to use dialer 1 as its backup interface: 

XSR (conf ig) #interf ace serial 1/1 

XSR (conf ig-if <S1/1>) #backup interface dialerl 

XSR (conf ig-if <S1/1>) #backup delay 110 

XSR (conf ig-if <S1/1>) #no shutdown 

Configure primary serial port to use dialer 2 as its backup interface: 

XSR (conf ig) #interf ace serial 1/2 

XSR (conf ig-if <Sl/2>) #backup interface dialer2 

XSR (conf ig-if <Sl/2>) #backup delay 1 10 

XSR (conf ig-if <Sl/2>) #no shutdown 
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Overview of Dial on Demand/Bandwidth on Demand 

The XSR's Dial on Demand /Bandwidth on Demand applications provide 
high-speed, available-when-needed dial services over point-to-point or 
multipoint PPP ISDN connections. Different network topologies can be 
configured for different applications - mainly under Dialer Interface 
configuration mode - including the following: 

□ Dial on Demand 

- PPP Point to Multipoint 

- PPP Multi to Multipoint 

- MLPPP Point to Multipoint 

- MLPPP Multi to Multipoint 

- Incoming Call Mapping 

□ Switched PPP Multilink 

- Bandwidth on Demand 

□ Backup 

Backup using ISDN 

- Backup with MLPPP 

The caveats below apply to the XSR/s support of switched multilink 
connections: 

□ They use the dialer and are set up in Dialer interface mode and must 
include an ISDN interface or associated modem. 

□ Configuring switched connections on a Serial line is unnecessary, the 
process is performed automatically. 

□ Leased-line connections are supported and must be configured in 
Multilink interface mode. 

□ Support on FastEthernet/ GigabitEthernet ports is not available. 

For more information on ISDN fundamentals, refer "Configuring Integrated 
Services Digital Network (ISDN)" on page 187 and the XSR CLI Reference 
Guide. 

Optional commands shown in sample configurations are preceded by an 
exclamation point. 
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Answering Incoming ISDN Calls 

The XSR handles incoming ISDN calls as follows: 

□ Always accepts incoming calls. 

□ If there is only one dialer interface configured it will bind the 
incoming call to that interface. 

□ If there is more than one dialer interface configured, the XSR will 
attempt to map the incoming call to only one of these interfaces based 
on any of the following data passed by the ISDN switch: 

Called number. 

- Calling number. 

□ Mapping based on the called number is performed if the following 
conditions are met: 

- The ISDN switch passes called number data to the XSR. Note that 
not all types of switches can provide this information. 

- The called number is configured under the target dialer interface 
using the dialer called command. 

□ Mapping based on the calling number is performed if the following 
conditions are met: 

- The ISDN switch passes the calling number to the XSR data. Note 
that not all types of switches can provide this information. 

- The calling number is configured under the target dialer interface 
using the dialer caller command. 

□ Incoming calls may be mapped to a dialer interface based on the PPP 
authenticated username if the following conditions are met: 

- The username must be configured under the dialer interface 
using the dialer remote -name command. 

- Interface dialer 0 is configured with the desired PPP 
authentication (e.g., ppp authentication pap). 

□ In the case where a dialer interface is configured for multipoint 
operation using the dialer map command, incoming calls are 
mapped based on the calling number matching the dialer string set by 
the map or on the PPP authenticated username matching the name set 
by the dialer map command. 

□ In the case where no dialer interface is found using the methods 
described above, the XSR will display a high severity alarm stating 
cannot bind inbound call and will disconnect the ISDN call. 
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Incoming Call Mapping Example 

This example, as shown in Figure 26, configures a node capable of handling 
multiple call setup requests coming from different remote peers and maps 
each incoming call to the correct IP interface (Dialer interface). 



IP address 10.10.10.1 
phone# 2300 
name toronto 




IP address 20.20.20.4 
phone# 2600 
name boston 



IP address 10.10.10.2 
IP address 20.20.20.2 
phone# 2400 



Kl Node B 
]A [XSR] 



Figure 26 Incoming Call Mapping Topology 



Node A (Calling Node) Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR(conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 25 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands define a dialer group, add a dialer pool, set a 25- 
second idle timeout, and map BRI interface 1/0 to Dialer interface 1. The 
dialer map command directs Node A to call Node B, specifying Node B's IP 
address and phone number as well as enables spoofing on the network. 
Optionally, you can specify a clear text password be sent to the peer for PAP 
authentication. 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
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XSR (conf ig-if <D1>) dialer pool 25 
XSR (conf ig-if <D1>) encapsulation ppp 

! XSR (conf ig-if <D1>) #ppp pap sent-username toronto password q 

XSR (conf ig-if <D1>) dialer idle- timeout 20 

XSR (conf ig-if <D1>) dialer-group 3 

XSR (conf ig-if <D1>) dialer map ip 10.10.10.2 2400 

XSR(config-if<Dl>) ip address 10.10.10.1 255.255.255.0 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 101 to pass all Type 8 source and destination ICMP packets 
up to 20 idle seconds: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

The following command maps ACL 101 to dialer group 3: 
XSR (conf ig) #dialer-list 3 protocol ip list 101 

Node B (Called Node) Configuration 

The following commands add two users to validate calls made from Node A. 
This configuration employs the username /authentication method of mapping 
incoming calls. 

XSR (conf ig) #username toronto privilege 0 password cleartext z 
XSR (conf ig) #username boston privilege 0 password cleartext y 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 22 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands configure Dialer inter 0 on BRI interface 1/0: 

XSR (conf ig) #interf ace dialer 0 

XSR (conf ig-if <D0>) encapsulation ppp 

XSR (conf ig-if <D0>) ppp authentication pap 

The following commands add a dialer pool and map BRI interface 1 /0 to 
Dialer interface 1. The dialer called command maps incoming Node A 
calls to Node B's 2400 number. Optionally, you can employ the dialer caller 
method and specify a PPP authenticated username to map incoming calls. 
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XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if<Dl>) dialer pool 22 

XSR (conf ig-if <D1>) encapsulation ppp 

XSR (conf ig-if <D1>) dialer called 2400 

! dialer caller 2300 

! dialer remote-name toronto 

XSR (conf ig-if <D1>) ip address 10.10.10.2 255.255.255.0 

The following commands add a dialer pool and map BRI interface 1/0 to 
Dialer interface 2. The dialer called command maps incoming Node A 
calls to Node B's 2400 number. Optionally, you can employ the dialer caller 
method and specify a PPP authenticated username to map incoming calls. 

XSR (conf ig) #interf ace dialer 2 

XSR (conf ig-if <D2>) #no shutdown 

XSR (conf ig-if <D2>) #dialer pool 22 

XSR (conf ig-if <D2>) #dialer called 2400 

! dialer caller 2600 

! dialer remote-name boston 

XSR (conf ig-if <D2>) #encapsulation ppp 

XSR(conf ig-if<D2>) #ip address 20.20.20.2 255.255.255.0 

The following command shuts down the SNMP server to avoid saving 
extraneous messages: 

XSR (conf ig) #snmp- server disable 

Node D (Calling Node) Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 2 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands define a dialer group, add a dialer pool, set a 20- 
second idle timeout, and map BRI interface 1/0 to Dialer port 1. The dialer 
map command directs Node D to call Node B, specifying Node B's IP address 
and phone number as well as enables spoofing on the network. Optionally, 
you can set a clear text password be sent to the peer for PAP authentication. 
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XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if<Dl>) dialer pool 2 

XSR (conf ig-if <D1>) encapsulation ppp 

• PPP P a P sent-username boston password orbitor 

XSR (conf ig-if <D1>) dialer idle- timeout 20 

XSR (conf ig-if <D1>) dialer-group 7 

XSR (conf ig-if <D1>) dialer map ip 20.20.20.2 2400 

XSR(config-if<Dl>) ip address 20.20.20.4 255.255.255.0 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 106 to pass all Type 8 source and destination ICMP packets 
up to 20 idle seconds: 

XSR (conf ig) access -list 106 permit icmp any any 8 

The following command maps ACL 1061 to dialer group 7: 
XSR (conf ig) #dialer-list 7 protocol ip list 106 



Configuring DoD/BoD 

The XSR supports Bandwidth-on-Demand (BoD), the ability to dynamically 
change bandwidth during a multilink connection. DoD/BoD is performed by 
configuring the following on a multilink bundle: 

□ The dialer idle timeout value to bring down an idle link when 
triggered by interesting traffic specified by an Access Control List 
(ACL). The link is brought down by the calling node. 

□ The multilink load threshold to trigger the dialer to add or delete a link. 
This feature is controlled by the calling node. 

□ The minimum links value to maintain on the bundle. This feature is 
controlled by the calling node. 

□ Bandwidth Allocation Protocol (BAP) values to negotiate with the 
peer to add or drop links. 

For information on configuring BAP on Dialer interfaces, refer to 
"Configuring PPP" on page 103. 

An example of the XSR's Dial on Demand functionality is illustrated in the 
topology shown in Figure 27. 
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IP address 10.10.10.2 
IP address 20.20.20.2 
phone# 2400 



NodeB 



IP address 10.10.10.1 
phone# 2300 



Node A 
[XSR] 




[XSR] 



Figure 27 Dial on Demand Topology 

{ / note 

Configuration commands preceded by an exclamation point ( ! ) are 
optional. 



PPP Point-to-Multipoint Configuration 

In this configuration, only one of the peer nodes can initiate the setup of a 
switched link when access-list defined data traffic is sent to the remote peer. 

Node A (Calling Node) Configuration 

The following commands add a dialer pool and dialer group, and set the 
Central Office switch type on BRI port 1/0. The commands also configure 
Dialer interface 1 with spoofing enabled on Node A's network, and set calls 
out to Node B to terminate if the line is idle for 20 seconds. 
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XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 

XSR (conf ig-if <BRI-l/0>) #dialer pool-member 25 

XSR (conf ig-if <BRI-l/0>) #no shutdown 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if <D1>) #dialer pool 25 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #dialer idle- timeout 20 

XSR (conf ig-if <D1>) #dialer -group 3 

XSR (conf ig-if <D1>) #dialer map ip 10.10.10.2 2400 

XSR (conf ig-if <D1>) #ip address 10.10.10.1 255.255.255.0 

The following optional commands can be entered to add a second, similarly 
configured, Dialer interface to the dialer group: 

! XSR (conf ig) #interf ace dialer 2 

! XSR (conf ig-if <D2>) #no shutdown 

! XSR (conf ig-if <D2>)#dialer pool 25 

! XSR (conf ig-if <D2>) #encapsulation ppp 

! XSR (conf ig-if <D2>) #dialer idle- timeout 20 

! XSR (conf ig-if <D2>) #dialer-group 3 

! XSR (conf ig-if <D2>) #dialer map ip 20.20.20.2 2401 

! XSR (conf ig-if <D2>)#ip address 20.20.20.1 255.255.255.0 

The following command defines interesting packets for the dial out trigger by 
configuring access list 101 to pass all Type 8 source and destination ICMP 
traffic up to 20 idle seconds: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

The following command maps ACL 101 to dialer group 3: 
XSR (conf ig) #dialer-list 3 protocol ip list 101 

Node B (Called Node) Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 22 
XSR (conf ig-if <BRI-l/0>) #no shutdown 
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The following commands add a dial pool and map BRI interface 1/0 to Dialer 
interface 1. Optionally, you can employ the dialer called method to map 
incoming Node A calls to Node B's phone number and add a second Dialer 
interface with similar mappings. 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if<Dl>) #dialer pool 22 
XSR (conf ig-if <D1>) #encapsulation ppp 
! dialer called 2400 

XSR (conf ig-if <D1>) #ip address 10.10.10.2 255.255.255.0 

! XSR (conf ig) #interf ace dialer 2 

! XSR (conf ig-if <D2>) #no shutdown 

! XSR (conf ig-if <D2>) #dialer pool 22 

! XSR (conf ig-if <D2>) #encapsulation ppp 

! XSR (conf ig-if <D2>)#dialer called 2401 

! XSR (conf ig-if <D2>)#ip address 20.20.20.2 255.255.255.0 

PPP Multipoint-to-Multipoint Configuration 

The following configuration sets both peer nodes to initiate the setup of a 
switched link when access list-defined data traffic is sent to the remote peer. 
The configuration of the two nodes is symmetrical, that is, both nodes can 
make and receive calls. 

Node A Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 25 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands define a dial group, add a dial pool, configure 
Dialer interface 1 with spoofing enabled on XSR-Andover network, and set 
calls out to XSR-Toronto to terminate if the line is idle for 35 seconds: 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if <D1>) #dialer pool 25 
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XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #dialer idle- timeout 35 

XSR (conf ig-if <D1>) #dialer-group 3 

XSR (conf ig-if <D1>) #dialer map ip 10.10.10.2 2400 

XSR(config-if<Dl>) #ip address 10.10.10.1 255.255.255.0 

The following command defines interesting packets for the dial out trigger by 
configuring access list 101 to pass all Type 8 source and destination ICMP 
traffic up to 35 idle seconds: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

The following command maps ACL 101 to dialer group 3: 
XSR (conf ig) #dialer-list 3 protocol ip list 101 

Node B Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 22 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands add a dialer pool and dialer group, and specify 
MLPPP call destination Node A on Node B's Dialer interface 1. If the line is idle 
for 30 seconds, it is brought down. 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if <D1>) #dialer pool 22 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #dialer-group 7 

XSR (conf ig-if <D1>) #dialer idle- timeout 30 

XSR (conf ig-if <D1>) #dialer map ip 10.10.10.1 2300 

XSR (conf ig-if <D1>) #ip address 10.10.10.2 255.255.255.0 

The following command defines interesting packets for the dial out trigger by 
configuring access list 105 to pass all Type 8 source and destination ICMP 
traffic up to 30 idle seconds: 

XSR (conf ig) #access-list 105 permit icmp any any 8 
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The following command maps ACL 105 to dialer group 7: 
XSR (conf ig) #dialer- list 7 protocol ip list 105 

PPP Point-to-Point Configurations 

The following sample configuration is a PPP point-to-point topology, as 
illustrated in Figure 28. 
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Figure 28 Point-to-Point Topology 



Dial-in Routing for Dial on Demand Example 

The following commands configure dialer interface 1 with both PPP 
authentication enforced and specifies the PPP authenticated username XSR- 
Andover to map incoming calls to map incoming calls on XSR-Toronto: 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #encapsulation ppp 
XSR(conf ig-if<Dl>) #ip address 172.22.85.1 
XSR (conf ig-if <D1>) #ppp authentication pap 
XSR (conf ig-if <D1>) #dialer pool 1 
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XSR (conf ig-if <D1>) #dialer remote-name XSR-andover 
XSR (conf ig-if <D1>) #no shutdown 

The following command configures authentication of the remote user: 
XSR (conf ig) #username XSR-andover password secret 0 code 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 1 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

Dial-out Routing for Dial on Demand Example 

The following commands define a dial group, add a dial pool, specify a secret 
password to be sent to the peer for PAP authentication, configure Dialer 
interface 1 with spoofing enabled on XSR-Andover network, and set calls out 
to XSR-Toronto to terminate if the line is idle for 20 seconds: 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 172.22.85.2 

XSR (conf ig-if <D1>) #ppp pap sent-username XSR-andover password 
secret 0 dolly 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #dialer map ip 172.22.85.1 47410 

XSR (conf ig-if <D1>) #dialer-group 1 

XSR (conf ig-if <D1>) #dialer idle- timeout 20 

XSR (conf ig-if <D1>) #no shutdown 

The following commands add a dial pool member and set the Central Office 
switch type on BRI interface 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 1 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following command maps ACL 101 to dialer group 1: 
XSR (conf ig) #dialer-list 1 protocol ip list 101 
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The following command defines interesting packets for the dial out trigger by 
configuring access list 101 to pass all Type 8 source and destination ICMP 
traffic up to 20 idle seconds: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

PPP Point-to-Multipoint Configurations 

The following topology can be used for Dial on Demand applications only; it 
cannot be used for Dialed Backup applications. Refer to Figure 29. 
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Figure 29 PPP Point-to-Multipoint Topology 



Dial-out Router Example 

The following commands add a dialer pool and dialer group, specify a secret 
password to be sent to the peer for PAP authentication, and specify three 
MLPPP call destinations - XSR-Andover, XSR-Boston and XSR-Buffalo - on XSR- 
Torontos Dialer interface 1. Spoofing is enabled by the dialer map command. 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #encapsulation ppp 
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XSR(config-if<Dl>) #ip address 172.22.85.1 

XSR (conf ig-if <D1>) #ppp pap sent-username XSR-toronto password 
secret 0 xxgene 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #dialer map ip 172.22.85.2 4710 
XSR (conf ig-if <D1>) #dialer map ip 172.22.85.3 89302 
XSR (conf ig-if <D1>) #dialer map ip 172.22.85.4 672783 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if <D1>) #dialer-group 1 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 1 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following command maps ACL 101 to dialer group 1: 
XSR (conf ig) #dialer-list 1 protocol ip list 101 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 101 to pass Type 8 source and destination ICMP packets: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

Dial-in Router Example 

The following commands configure Dialer interface 0 to enforce 
authentication for incoming calls: 

XSR (conf ig) #interf ace dialer 0 

XSR (conf ig-if <D0>) #encapsulation ppp 

XSR (conf ig-if <D0>) #ppp authentication pap 

The following commands add a dialer pool and specify the PPP authenticated 
username of XSR-Toronto calling in to Dialer interface 1: 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 172.22.85.2 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if <D1>) #dialer remote-name XSR-toronto 
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The following commands add a dial pool and specifies the PPP authenticated 
username XSR-Boston to map incoming calls to Dialer interface 2: 

XSR (conf ig) #interf ace dialer 2 

XSR (conf ig-if <D2>) #encapsulation ppp 

XSR(config-if<D2>) #ip address 172.22.85.3 

XSR (conf ig-if <D2>) #dialer pool 1 

XSR (conf ig-if <D2>) #no shutdown 

XSR (conf ig-if <D2>) #dialer remote-name XSR-Boston 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 1 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following command sets remote user authentication: 

XSR (conf ig) #username XSR-toronto password secret 0 code 

MLPPP Point-to-Multipoint Configuration 

The following configuration, as illustrated in Figure 28, sets up a switched 
MLPPP group (bundle) when Access List-defined data traffic is generated to a 
remote site. 

i NOTE 

Only peer Node A can initiate the MLPPP group setup. 



Node A (Calling Node) Configuration 

The following commands add a dialer pool member with the Central Office 
switch type to BRI interface 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 25 
XSR (conf ig-if <BRI-l/0>) #no shutdown 
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The following commands define a dialer group, add a dialer pool, enable 
MLPPP, set a 20-second idle timeout, and map BRI interface 1 /0 to Dialer 
interface 1. The min- links command directs the XSR to maintain a 
minimum of two links over the switched line. The dialer map command 
directs Node A to call Node B, specifying Node B's IP address and phone 
number, as well as enables spoofing. 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if<Dl>) #dialer pool 25 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #dialer idle- timeout 20 

XSR (conf ig-if <D1>) #dialer -group 3 

XSR (conf ig-if <D1>) #dialer map ip 10.10.10.2 2400 

XSR (conf ig-if <D1>) #ip address 10.10.10.1 255.255.255.0 

XSR (conf ig-if <D1>) #ppp multilink 

XSR (conf ig-if <D1>) #multilink min-links 2 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 101 to permit all Type 8 source and destination ICMP traffic: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

The following command maps ACL 101 to dialer group 3: 
XSR (conf ig) #dialer-list 3 protocol ip list 101 

Node B (Called Node) Configuration 

The following commands add a dialer pool member with the Central Office 
switch type to BRI interface 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 22 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The commands below add a dialer pool and enable MLPPP on Dialer port 1: 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if <D1>) #dialer pool 22 
XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 10.10.10.2 255.255.255.0 
XSR (conf ig-if <D1>) #ppp multilink 
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MLPPP Point-to-Point Configurations 

The following MLPPP point-to-point topology can be used for Bandwidth on 
Demand applications, as illustrated by Figure 30. This example creates three 
switched lines linking users on XSR-Toronto's network with those on XSR- 
Andover's network. 
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Figure 30 MLPPP Point-to-Point Topology 



Dial-in Router Example 

The following commands add a dialer pool and configure Multilink PPP on 
XSR-Toronto's Dialer interface 1: 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 172.22.85.1 

XSR (conf ig-if <D1>) #ppp multilink 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #no shutdown 



XSR User's Guide 



173 



Configuring DoD/BoD 



Chapter 8 
Configuring Dialer Services 



The following commands add a dialer pool member and specify the primary- 
ni switch on XSR-Toronto's Tl interface 2/3: 

XSR(config) #controller tl 2/3 

XSR (conf ig-controller<Tl-l/l>) # switch -type primary -ni 
XSR (conf ig-controller<Tl-l/l>) #dialer pool-member 1 
XSR (conf ig-controller<Tl-l/l>) #no shutdown 

Dial-out Router Example 

The following commands add a dialer pool and dialer group, specify the call 
destination - XSR-Toronto - and configure Multilink PPP to bring up a 
minimum of two links on XSR-Andover's Dialer interface 1. Spoofing also is 
enabled by the dialer map command. 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 172.22.85.2 

XSR (conf ig-if <D1>) #ppp multilink 

XSR (conf ig-if <D1>) #multilink min-links 2 

XSR (conf ig-if <D1>) #dialer idle- timeout 20 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if <D1>) #dialer map ip 172.22.85.1 47410 
XSR (conf ig-if <D1>) #dialer-group 1 

The following commands add a pool member and configure the primary-ni 
switch on Tl interface 2/3: 

XSR (conf ig) #controller tl 2/3 

XSR (conf ig- control ler<Tl- 2/3 >) #switch- type primary-ni 
XSR (conf ig- control ler<Tl- 2/3 >) #dialer pool-member 1 
XSR (conf ig- control ler<Tl- 2/3 >) #no shutdown 

The following command maps ACL 101 to dialer group 1: 
XSR (conf ig) #dialer-list 1 protocol ip list 101 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 101 to pass all Type 8 source and destination ICMP traffic up 
to 20 idle seconds: 

XSR (conf ig) #access- list 101 permit icmp any any 8 
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MLPPP Point-to-Multipoint Configurations 

The following MLPPP point-to-multipoint topology can be used for BoD 
applications, as illustrated by Figure 31. This example creates multiple 
switched lines linking users on XSR-Toronto's network with those on three 
remote networks. 
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Figure 31 MLPPP Point-to-Multipoint Topology 



Dial-out Router Example 



The following commands add a dialer pool and dialer group, and specify 
three MLPPP call destinations - XSR-Andover, XSR-Boston and XSR-Buffalo - 
on XSR-Toronto's Dialer interface 1. Spoofing also is enabled by the dialer 
map command. 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #encapsulation ppp 
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XSR(config-if<Dl>) #ip address 172.22.85.1 

XSR (conf ig-if <D1>) #ppp multilink 

XSR(conf ig-if<Dl>) #dialer pool 1 

XSR (conf ig-if <D1>) #dialer idle- timeout 20 

XSR (conf ig-if <D1>) #dialer map ip 172.22.85.2 47410 

XSR (conf ig-if <D1>) #dialer map ip 172.22.85.3 425688 

XSR (conf ig-if <D1>) #dialer map ip 172.22.85.4 987762 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if <D1>) #dialer-group 1 

The following commands add a pool member and configure the primary-ni 
switch on Tl interface 2/3: 

XSR (conf ig) #controller tl 2/3 

XSR (conf ig- control ler<Tl- 2/3 >) #switch- type primary-ni 
XSR (conf ig- control ler<Tl- 2/3 >) #dialer pool-member 1 
XSR (conf ig- control ler<Tl- 2/3 >) #no shutdown 

The following command maps ACL 101 to dialer group 1: 
XSR (conf ig) #dialer-list 1 protocol ip list 101 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 101 to pass all Type 8 source and destination ICMP packets 
up to 20 idle seconds: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

Dial-in Router Exampie 

The following commands add a dialer pool and configure PPP Multilink on 
XSR-Andover's Dialer interface 1: 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 172.22.85.2 

XSR (conf ig-if <D1>) #ppp multilink 

XSR (conf ig-if <D1>) #dialer pool 1 

XSR (conf ig-if <D1>) #no shutdown 

The following commands add a pool member and configure the primary-ni 
switch on Tl interface 2/3: 

XSR (conf ig) #controller tl 2/3 

XSR (conf ig- control ler<Tl- 2/3 >) #switch- type primary-ni 
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XSR (conf ig-controller<Tl-2/3>) #dialer pool-member 1 
XSR (conf ig- control ler<Tl- 2/3 >) #no shutdown 

MLPPP Multipoint-to-Multipoint Configuration 

The following configuration, as shown in Figure 27, enables the setup of a 
switched MLPPP group when access list-defined data traffic is sent to a 
remote site. Both peer nodes can initiate and accept switched MLPPP calls. 

Node A Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 25 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands add a dialer pool and dialer group, and specify 
MLPPP call destination Node B on Node As Dialer interface 1. If the line is idle 
for 20 seconds, it is brought down. 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if <D1>) #dialer pool 25 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #dialer idle- timeout 20 

XSR (conf ig-if <D1>) #dialer -group 3 

XSR (conf ig-if <D1>) #dialer map ip 10.10.10.2 2400 

XSR(config-if<Dl>) #ip address 10.10.10.1 255.255.255.0 

XSR (conf ig-if <D1>) #ppp multilink 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 101 to pass all Type 8 source and destination ICMP packets 
up to 20 idle seconds: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

The following command maps ACL 101 to dialer group 3: 
XSR (conf ig) #dialer-list 3 protocol ip list 101 
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Node B Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 22 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands add a dialer pool and dialer group, and specify 
MLPPP call destination Node A on Node B's Dialer interface 1. Spoofing also is 
enabled by the dialer map command. 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if <D1>) #dialer pool 22 
XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 10.10.10.2 255.255.255.0 

XSR (conf ig-if <D1>) #dialer-group 3 

XSR (conf ig-if <D1>) #dialer idle- timeout 20 

XSR (conf ig-if <D1>) #dialer map ip 10.10.10.1 2300 

XSR (conf ig-if <D1>) #ppp multilink 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 101 to pass all Type 8 source and destination ICMP packets 
up to 20 idle seconds: 

XSR (conf ig) #access-list 101 permit icmp any any 8 

The following command maps ACL 101 to dialer group 3: 
XSR (conf ig) #dialer-list 3 protocol ip list 101 
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Switched PPP Multilink Configuration 



Bandwidth-on-Demand 

This example configures multilink PPP over ISDN together with BoD as 
shown in Figure 32. 
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Figure 32 MLPPP Bandwidth on Demand Topology 



Node A (Calling Node) Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR(conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 23 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands define a dialer group, add a dialer pool, enable 
MLPPP, set a load threshold of 3 links, and map BRI interface 1 /0 to Dialer 
interface 1. The load- threshold command enables BoD by making the 
XSR maintain three links over the switched line. The dialer map command 
directs Node A to call Node C, specifying Node C's IP address and phone 
number as well as enables spoofing on the network. 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if <D1>) #dialer pool 23 
XSR (conf ig-if <D1>) #encapsulation ppp 

XSR(config-if<Dl>) #ip address 10.10.10.1 255.255.255.0 
XSR (conf ig-if <D1>) #dialer map ip 10.10.10.3 2500 
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XSR (conf ig-if <D1>) #ppp multilink 

XSR (conf ig-if <D1>) #dialer-group 7 

XSR (conf ig-if <D1>) #multilink load- threshold 3 

XSR (conf ig-if <D1>) #dialer idle- timeout 20 

The following command defines interesting packets for the dial out trigger by 
configuring ACL 106 to pass all Type 8 source and destination ICMP packets 
up to 20 idle seconds: 

XSR (conf ig) #access-list 106 permit icmp any any 8 

The following command maps ACL 106 to dialer group 7: 
XSR (conf ig) #dialer-list 7 protocol ip list 106 

Node C (Called Node) Configuration 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 2 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands add a dialer pool, enable MLPPP, and map BRI 
interface 1/0 to Dialer interface 1. The dialer called command maps 
incoming Node A calls to its 2500 number: 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if <D1>) #dialer pool 2 
XSR (conf ig-if <D1>) #encapsulation ppp 
XSR (conf ig-if <D1>) #dialer called 2500 

XSR (conf ig-if <D1>) #ip address 10.10.10.3 255.255.255.0 
XSR (conf ig-if <D1>) #ppp multilink 
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Backup Configuration 



Backup Using ISDN 



This example configures ISDN NIM cards (either BRI or Tl/El configured for 
PRI) to be used for backing-up other interfaces, as shown in Figure 33. 



Node A 
[XSR] 



IP address 10.10.10.1 
IP address 20.20.20.1 
phone# 2300 




IP address 30.30.30.1 
IP address 40.40.40.1 



Primary leased 
backup lines 



IP address 10.10.10.3 
IP address 20.20.20.3 
phone# 2500/2501 



IP address 30.30.30.3 
IP address 40.40.40.3 



NodeC 
[XSR] 



Figure 33 Backup Topology Using ISDN 



Node A (Backed-up Node) Configuration 

The following commands set internal clocking and configure two channel 
groups with three total timeslots on Tl sub-interface 1/2:0: 

XSR(conf ig) #controller tl 1/2/0 

XSR (conf ig- con t roller <T1- 1/2 : 0>) #clock source internal 
XSR (conf ig-controller<Tl-l/2 : 0>) #channel -group 1 timeslots 2 
XSR (conf ig-controller<Tl-l/2 : 0>) #channel -group 0 timeslots 1 
XSR (conf ig-controller<Tl-l/2 : 0>) #no shutdown 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 22 
XSR (conf ig-if <BRI-l/0>) #no shutdown 
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The following commands add a dialer pool, set Node C's dialer number to 
call, specify a clear text password sent to the peer for PAP authentication, and 
map BRI interface 1/0 to Dialer interface 1. 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if<Dl>) #dialer pool 22 
XSR (conf ig-if <D1>) #dialer string 2500 
XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 10.10.10.1 255.255.255.0 

XSR (conf ig-if <D1>) #ppp pap sent-username toronto password ab 

The following commands add a dialer pool, set Node C's dialer number to 
call, and map BRI interface 1/0 to Dialer interface 2: 

XSR (conf ig) #interf ace dialer 2 
XSR (conf ig-if <D2>) #no shutdown 
XSR (conf ig-if <D2>) #dialer pool 22 
XSR (conf ig-if <D2>) #dialer string 2501 

XSR (conf ig-if <D2>) #ip address 20.20.20.1 255.255.255.0 

The following command configures backup Dialer interface 1 on Serial sub- 
interface 2/0:0: 

XSR (conf ig) #interf ace serial 2/0:0 

XSR (conf ig-if <S2/0 : 0>) #no shutdown 

XSR (conf ig-if <S2/0 : 0>) #backup interface dialerl 

XSR (conf ig-if <S2/0 : 0>) #encapsulation ppp 

XSR(config-if<S2/0:0>) #ip address 30.30.30.1 255.255.255.0 

The following command configures backup Dialer interface 2 on Serial sub- 
interface 2/0:1: 

XSR (conf ig) interface serial 2/0:1 

XSR (conf ig-if <S2/0 : 1>) #no shutdown 

XSR (conf ig-if <S2/0 : 1>) #backup interface dialer 2 

XSR (conf ig-if <S2/0 : 1>) #encapsulation ppp 

XSR(config-if<S2/0:l>) #ip address 40.40.40.1 255.255.255.0 

Node C (Called Node) Configuration 

The following command configures a Node A user for authentication: 
XSR (conf ig) #username toronto privilege 0 password cleartext z 
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The following commands configure two channel groups with a total of three 
timeslots on Tl sub-interface 1/2:0: 

XSR(config) #controller tl 1/2/0 

XSR (conf ig-controller<Tl-l/2 : 0>) #channel -group 1 timeslots 2 
XSR (conf ig-controller<Tl-l/2 : 0>) #channel -group 0 timeslots 1 
XSR (conf ig-controller<Tl-l/2 : 0>) ) #no shutdown 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 28 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

One of the following commands sets PAP authentication on Dialer interface 0: 

XSR (conf ig) #interf ace dialer 0 

XSR (conf ig-if <D0>) #encapsulation ppp 

XSR (conf ig-if <D0>) #ppp authentication pap 

The following commands add a dialer pool and specify the PPP authenticated 
username Toronto to map incoming calls on Dialer interface 1: 

XSR (conf ig) #interf ace dialer 1 

XSR (conf ig-if <D1>) #no shutdown 

XSR (conf ig-if <D1>) #dialer pool 28 

XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #dialer remote-name Toronto 

XSR (conf ig-if <D1>) #ip address 10.10.10.3 255.255.255.0 

The following commands add a dialer pool and map incoming Node A calls 
to Node Cs 2500 number: 

XSR (conf ig) #interf ace dialer 2 
XSR (conf ig-if <D2>) #no shutdown 
XSR (conf ig-if <D2>) #dialer pool 28 
XSR (conf ig-if <D2>) #encapsulation ppp 
XSR (conf ig-if <D2>) #dialer called 2501 

XSR(conf ig-if<D2>) #ip address 20.20.20.3 255.255.255.0 

The following command configures Serial sub-interface 2/0:0: 
XSR (conf ig) #interf ace serial 2/0:0 
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XSR (conf ig-if <S2/0 : 0>) #no shutdown 

XSR (conf ig-if <S2/0 : 0>) #encapsulation ppp 

XSR(config-if<S2/0:0>) #ip address 30.30.30.3 255.255.255.0 

The following command configures Serial sub-interface 2/0:1: 

XSR (conf ig) #interf ace serial 2/0:1 
XSR (conf ig-if <S2/0 : 1>) #no shutdown 
XSR (conf ig-if <S2/0 : 1>) #encapsulation ppp 

XSR(config-if<S2/0:l>) #ip address 40.40.40.3 255.255.255.0 

Configuration for Backup with MLPPP Bundle 

Node A (Backed-up Node) Configuration 

The following commands set internal clocking and configure two channel 
groups with three total timeslots on Tl sub-interface 1/2:0: 

XSR (conf ig) #controller tl 1/2/0 

XSR (conf ig-controller<Tl-l/2 : 0>) #clock source internal 
XSR (conf ig-controller<Tl-l/2 : 0>) #channel -group 1 timeslots 2 
XSR (conf ig-controller<Tl-l/2 : 0>) #channel -group 0 timeslots 1 
XSR (conf ig- control ler<Tl- 1/2 : 0>) #no shutdown 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 22 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands add a dialer pool, enable MLPPP, specify Node A to 
call Node C by entering Node C's phone number, and map BRI interface 1/0 
to Dialer interface 1. The min- links command directs the XSR to maintain a 
minimum of two links over the switched line. 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if <D1>) #dialer pool 22 
XSR (conf ig-if <D1>) #dialer string 2500 
XSR (conf ig-if <D1>) #encapsulation ppp 

XSR(config-if<Dl>) #ip address 10.10.10.1 255.255.255.0 
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XSR (conf ig-if <D1>) #ppp multilink 

XSR (conf ig-if <D1>) #multilink min-links 2 

The following command configures Serial sub-interface 2/0:0: 

XSR (conf ig) #interf ace serial 2/0:0 

XSR (conf ig-if <S2/0 : 0>) #no shutdown 

XSR (conf ig-if <S2/0 : 0>) #backup interface dialerl 

XSR (conf ig-if <S2/0 : 0>) #encapsulation ppp 

XSR(config-if<S2/0:0>) #ip address 30.30.30.1 255.255.255.0 

Node C (Called Node) Configuration 

The following commands configure two channel groups with three total 
timeslots on Tl sub-interface 0/2:0: 

XSR (conf ig) #controller tl 0/2/0 

XSR (conf ig- control ler<Tl- 0/2 : 0>) #channel -group 1 timeslots 2 
XSR (conf ig- control ler<Tl- 0/2 : 0>) #channel -group 0 timeslots 1 
XSR (conf ig- control ler<Tl- 0/2 : 0>) #no shutdown 

The following commands add a dialer pool member and set the Central Office 
switch type on BRI port 1/0: 

XSR (conf ig) #interface bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-net3 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 28 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

The following commands add a dialer pool, enable MLPPP, and map BRI 
interface 1/0 to Dialer interface 1: 

XSR (conf ig) #interf ace dialer 1 
XSR (conf ig-if <D1>) #no shutdown 
XSR (conf ig-if <D1>) #dialer pool 28 
XSR (conf ig-if <D1>) #encapsulation ppp 

XSR (conf ig-if <D1>) #ip address 10.10.10.3 255.255.255.0 
XSR (conf ig-if <D1>) #ppp multilink 

The following commands configure Serial sub-interface 2/0:0: 

XSR (conf ig) #interf ace serial 2/0:0 
XSR (conf ig-if <S2/0 : 0>) #no shutdown 
XSR (conf ig-if <S2/0 : 0>) #encapsulation ppp 

XSR(config-if<S2/0:0>) #ip address 30.30.30.3 255.255.255.0 
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Configuration for Ethernet Failover 

This example provides DSL backup (PPPoE) on a FastEthernet interface. 
Dialer interface 57 is configured as the backup for FastEthernet sub-interface 
2.1 - invoking the sub-interface enables PPPoE. Note that the IP address of the 
PPPoE caller is negotiated over PPP and the MTU size is reset to 1492 bytes to 
avoid Web access problems by PCs attached to the XSR. 

XSR (conf ig) #interf ace fastethernet 2 
XSR (conf ig-if <F2>) #no shutdown 



XSR (conf ig) #interf ace fastethernet 2.1 
XSR (conf ig-if >) #backup interface dialer 57 
XSR (conf ig-if >) #encapsulation ppp 
XSR (conf ig-if >) #ip address negotiated 
XSR(conf ig-if >) #ip mtu 1492 
XSR (conf ig-if >) #no shutdown 
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This chapter outlines how to configure the Integrated Services Digital 
Network (ISDN) Protocol on the XSR in the following sections: 

□ XSR ISDN features 

□ Understanding ISDN 

□ ISDN configuration topology 

- BRI 

- PRI 

- Leased line 

□ ISDN configuration examples 

- Tl PRI 

- El PRI 

- ISDN BRI 

- BRI Leased 

- BRI Leased PPP 

- BRI Leased Frame Relay 

□ Call Status Call Codes 

ISDN Features 

The XSR's BRI interface and Tl/El controller in PRI mode acts as a utility that 
can set up and tear down calls under the control of higher level functionality, 
usually the Dialer. The ISDN module expects to receive from the Dialer a full 
description of the call to be placed and will accept incoming calls only if 
screened by the Dialer. The XSR's ISDN services BRI and PRI lines via the 
following NIMs: 

□ 1, 2 or 4 port Channelized NIM card for PRI lines. 
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□ 1 or 2 port BRI-S/T NIM card. 

□ 1 or 2 port BRI U NIM card. 

BRI Features 

□ Circuit Mode Data (CMD): Channels (DSOs or B / s)are switched by the 
CO to the destination user for the duration of the call. 

Outgoing calls supported for Backup, DoD/BoD. 
Incoming calls routed to the correct protocol stack based on 
called number/ sub-address and calling number/ sub-address. 

□ Permanent B channel support, i.e., 56, 64, 112, 128, or 144 Kbps lease 
line. Each BRI port can be configured for CMD or Leased-Line mode 
of operation. 

□ Supported switches: Net3 (ETSI) for international applications, Nil 
and DMS100 for North American applications and NTT for Japan. 

□ TEI auto-negotiated. 

□ Q.921/Q.931 (Layer 2/Layer 3) configuration is set automatically by 
selection of switch type. 

PRI Features 

□ Circuit Mode Data (CMD): Channels (DSOs or B's) are switched by 
the CO to the destination user for the duration of the call. 

- Outgoing calls supported for Backup, DoD/BoD. 

Incoming calls routed to the correct protocol stack based on 
called number/ sub-address and calling number/ sub-address. 

□ Supported switches: Net5 (ETSI) for international applications; NI2, 
5ESS, and DMS100 for North American applications; and NTT for 
Japan. 

□ Handling restart and maintenance modes automatically set. 

□ Fixed TEI to 0. 

□ Q921/Q931 (Layer 2/Layer 3) configuration is set automatically by 
the selection of the switch type. 
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Understanding ISDN 

Physically, an ISDN line is provisioned via unshielded twisted pair cable 
which would, in the absence of ISDN service, be used for regular analog 
telephone service or a Tl/El connection. 

Typically, numerous ISDN devices connect onto this single line through a 
device known as an NT1 provided by the user in North America and by the 
carrier most everywhere else. PRI service is terminated in the XSR's Tl/El 
NIM the same way as El or Tl service. BRI service is connected to the XSR's 
BRI-S/T NIM via a interface adapter known as NT1. The NT1 is provided by 
the service provider. Only in North America do users have to provide their 
own NT1. The BRI U NIM can be connected directly to incoming BRI lines in 
North America as they include a built-in NT1. 

Logically, ISDN consists of two types of communications channels: bearer 
service B-channels, which carry data and services at 64 Kbps; and a single D- 
channel (delta), which usually carries signaling and administrative 
information which is used to set up and tear down calls. The transmission 
speed of the D-channel depends on the type of ISDN service you've 
subscribed to. 

Available ISDN services include two categories: Basic Rate Interface (BRI) 
service, which provides access to two B-channels and a 16 Kbps D-channel; 
and Primary Rate Interface (PRI) service, which provides access to 23 B- 
channels in North America and Japan and 30 B-channels in Europe and most 
of Asia, and a 64 Kbps D-channel in both. 

Basic Rate Interface 

The XSR's BRI NIM provides two BRI ports. Each port has two 64 Kbps B- 
channels and one 16 Kbps D-channel. BRI is configured on the XSR by 
interface bri sub-commands. 

Primary Rate Interface 

ISDN PRI is provisioned over Tl service in North America and Japan and 
includes one 64 Kbps D-channel and 23 B-channels, and over El service 
includes 30 B-channels in most other parts of the world. 
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The number of B-channels is limited by the size of the standard trunk line 
used in the region; Tl in North America and Japan and El most everywhere 
else. Unlike BRI, PRI does not support a bus configuration, and only one 
device can be connected to a PRI line - point-to-point service. 

A single PRI connection is usually much less expensive than obtaining the 
equivalent number of B-channels through multiple BRI connections. BRI and 
PRI are used for the same applications, only the number of channels differ. 
PRI is configured on the XSR by controller tl/el sub-commands. 

B-Channels 

The XSR's B-channels are 56 or 64 Kbps "pipes" also known as DSOs. B- 
channels typically form circuit-switched connections. Just like a telephone 
connection, a B-channel connection is an end-to-end physical circuit that is 
temporarily dedicated to transferring data between two devices. The circuit- 
switched nature of B-channel connections, combined with their reliability and 
relatively high bandwidth, makes ISDN suitable for a range of applications 
including video, fax, and data. They can be used to transfer any Layer 2 or 
higher protocols across a link. The XSR employs PPP or Multilink PPP over 
the switched BRI or PRI connections. For more information, refer to the PPP 
and MLPPP chapters in this manual. 

The router's B-channels can also be configured as permanent or nailed-up 
connections which are always up, as a leased-line application similar to the 
channelized Tl/El application. 

D-Channel 

The XSR's D-channel is used for signaling, such as instructing the ISDN 
carrier to set up or tear down a call along a B-channel, to ensure that a B- 
channel is available to receive an incoming call, or to provide the signaling 
information that is required for such features as caller identification. The D- 
channel uses packet-switched connections, which are best adapted to the 
intermittent but latency-sensitive nature of signaling traffic, thus accounting 
for the vastly reduced call setup time of 1 to 2 seconds on ISDN calls (vs. 10 to 
40 seconds using an analog modem). 
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Unlike the B-channel, which functions as a simple pipe for user data, the D- 
channel is associated with higher level protocols, Layer 2: Q.921 and 3: Q.931 
of the OSI model. 

Q.931 is the call-control protocol component of this definition, although 
various carriers tend to use variants. This Layer 3 signaling protocol is 
transferred on the D-channel using Link Access Procedure-D-channel 
(LAPD): Q.921, a Layer 2 HDLC-like protocol. 

D-Channel Standards 

The XSR supports several D-channel standards, which are enabled with the 
isdn switch- type command. The accepted standards and some associated 
switches are: 

□ Europe/ International: basic-net 3 for BRI and primary-net 5 for PRI 

□ Japan: basic-ntt for BRI and primary-ntt for PRI 

□ North America: basic-nil and basic-dmslOO switches for BRI and 
primary-nil, primary-bess , and primary-dmslOO for PRI 

D-Channel Signaling and Carrier Networks 

When the ISDN carrier receives a Q.931 instruction from a remote location, 
for example, to set up a call, it triggers network switches to set up an end-to- 
end 64 Kbps B-channel between the source and the destination directory 
number signaled by Q.931. The carrier's network uses a different signaling 
system though. Signaling between remote ISDN devices and the public voice 
and data network switches occurs using D-channel protocols such as Q.931, 
which in turn is converted into Signaling System No. 7 (SS7) signals within 
the carrier's digital voice and data networks. With SS7, carriers are able to 
maintain clear channel 64 Kbps connections by communicating signaling data 
in a distinct channel. The switch at the destination side of the network then 
communicates with the remote ISDN device using its D-channel protocol. 

Unfortunately, SS7 is not always fully implemented, leading to occasional 
limitations when ISDN links traverse multiple switches. For instance, if one 
switch does not fully support SS7 ISDN features, call setup and signaling 
messages must be sent in-band or through the same communications channel 
as the bearer service. In other words, 8 Kbps of a 64 Kbps B-channel must be 
reserved for signaling, thus reducing available bandwidth. 
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This explains the 56 in switched-56 services, which also use 8 Kbps of a 64 
Kbps channel for signaling. Any ISDN call that passes through at least one 
network which lacks full SS7 signaling, must then limit its B-channel traffic to 
56 Kbps. In such cases the ISDN equipment on both ends must be configured 
to put only 56 Kbps of data onto their 64 Kbps link. As networks have 
continued to modernize, the use of 56 Kbps connection has diminished. 

The XSR automatically adapts to the speed of incoming calls, whether 56 or 64 
Kbps. When dialing over ISDN in North America, users can set the call speed 
by specifying 64 (default) or 56 Kbps. If the network can not connect at 64 
Kbps, it will be rejected and the router will try to redial (if redial attempts are 
set). If users wish to be sure that their calls will succeed, the XSR will request 
all outgoing calls be set at 56 Kbps. Consult "Configuring Dialer Services" on 
page 135 for more detailed information. 

To support 56 Kbps, communications equipment at both ends must support a 
rate adaptation scheme which pads bandwidth above 56 Kbps with blank data, 
using such schemes as V.110 or V.120 rate adaptation. This feature is usually 
required whenever an ISDN call originates in, is destined for, or passes 
through the U.S., where 56 Kbps ISDN connections are not uncommon. 

ISDN Equipment Configurations 

In a BRI configuration, an ISDN adapter, also known as a Terminal Adapter 
(TE), connects directly to NT1 network terminating equipment. This device is 
provided by a service provider except in North America where users must 
supply their own NT1 or order a BRI U-interface NIM with a built-in NT1. 

The NT1 delimits between U and S/T reference points. The U reference point 
represents the last section of the network that connects the Central Office with 
a customer's premises while the S/T reference point represents the customer 
premises' wiring. S/T is a point-to-multipoint wiring configuration, that is, 
the NTI can be connected to as many as eight TEs that contend for the two B 
channels. Most XSR applications are critical and require point-to-point 
connections with the ISDN service to ensure that the B channels are available 
in a timely fashion. International users are limited to ordering the S/T NIM as 
it is the only approved device for connection to the network. North American 
users can order U or S/T NIMs depending on wiring premises' requirements. 
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Bandwidth Optimization 

The XSR offers features which reduce call connection time and prevent 
network overhead from triggering ISDN calls. 

Dial-on-Demand (DoD) processes data calls strictly as needed, when 
interesting packets must be passed to specific destinations. 

Bandwidth-on-Demand (BoD) allocates ISDN bandwidth as efficiently as 
possible to accommodate varying traffic loads. The first element of this 
feature set is short-hold mode, which prevents links from forming in the 
absence of data traffic, while simulating continuous connections. 

For instance, suppose a remote workstation was connected to the corporate 
LAN via ISDN, but no data was being sent because a user's PC was idle. With 
short-hold mode, in the absence of any data traffic the ISDN call would be 
brought down, although from the user's perspective the link/ route would 
still be active, since any data transfer would automatically (and 
transparently) bring up an ISDN call. 

The second element of BoD directs that as traffic requirements increase or 
decrease, B-channels can be added or subtracted to best accommodate the 
load. This dynamic form of channel aggregation is often used by Multilink 
PPP which aggregates channels across multiple B channels of one or more 
BRI/PRI ports. The XSR implements this element of BoD with the multilink 
load- threshold, multilink min- links, and bap set of commands. 

To further make BoD work properly, the XSR also implements filtering and 
protocol spoofing in order to prevent network overhead such as RIP updates 
from needlessly bringing up the ISDN link. Although some of these frames 
can be discarded without any negative consequences, most are required to 
keep workstations and servers across the entire enterprise network 
synchronized with one another. 

The XSR filters unnecessary overhead by the use of Access Control Lists 
specifying interesting packets, and by spoofing protocol overhead packets to 
maintain the routes while keeping ISDN connection costs under control. 

The XSR performs LAN spoofing where on demand calls spoof RIP or OSPF 
updates - RIP updates are sent over the WAN only when changes to the 
network occur and are piggy-backed with data traffic. The dialer map 
command is used to enable spoofing. 



XSR User's Guide 



193 



Understanding ISDN 



Chapter 9 

Configuring Integrated Services Digital Network (ISDN) 



Security 

Security is another important element of dial-up data communications, and 
ISDN can support the security features of protocols running through it, as 
well as its own unique mechanisms. ISDN, in addition to supporting the 
standard authentication schemes of protocols riding on it (e.g. PPP's 
PAP/ CHAP protocols), enhances the security of dial-up connections with call 
number identification. 

With support for call number identification invoked by the isdn calling- 
number command, the XSR enables the comparison of incoming callers' phone 
numbers with a list of acceptable numbers. Calls can then be restricted to pre- 
screened locations, a definite advantage especially when PAP/ CHAP 
authentication is unavailable. 

Call Monitoring 

Call monitoring is also an important element of the XSR's ISDN service. Call 
monitoring features are useful in terms of security, but also enable tracking of 
call volume and logging of all connections so that administrators can 
optimize the number of ISDN lines ordered. Given that ISDN costs are often 
usage-related, this checking and recording also can prevent nasty surprises 
that users might receive with the monthly phone bill. At the same time, usage 
logs can provide managers with the justification required to add ISDN lines 
as the need for additional bandwidth arises. 

The show interface bri, show controllers bri, and show isdn service 

commands display virtual and physical line attributes including B channel 
idle warnings. 

The show isdn history and show isdn active commands display Cause 
Codes giving the reason why a call was disconnected. These codes are 
detailed in Table 9 on page 203. 
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ISDN Configuration 

PRI interfaces share the Tl/El NIM card and all physical configuration 
values the controller can configure. The pri -group command assigns the 
channels (DSOs) of the Tl/El port to ISDN module control. Interfaces are 
configured one of two ways using the following commands: 

□ The pri -group command ISDN switching. 

□ The channel -group command for point-to-point connections. 

The above commands are mutually exclusive: you can enter one or the other 
per PRI interface, not both. On the El NIM, 30 channels are controlled by 
ISDN, and 23 channels on the Tl NIM. Other PRI commands include: 

□ bchan- number -order selects a channel from Bl (ascending) or 
B23/B32 (descending). 

□ calling -number configures an outgoing ISDN calling number. 

□ switch - type specifies the Central Office ISDN switch type. 

BRI interfaces utilize a BRI-S/T or UNIM card. From a software perspective, 
S/T and U cards are equivalent and all features supported on both cards are 
equivalent. The card type is significant during installation only. In North 
America, the U card is connected directly to the ISDN service jack, the S/T 
card requires an external NT1 device to be connected between the S/T card 
and the service jack. Outside North America, only the S/T card is used with 
very few exceptions. 

The two basic modes of operation of the BRI card are: CMD switched mode 
and leased line (permanent) mode. Leased line mode is configured similar to 
Tl/El channelized operation mode - commands are entered at Controller 
configuration mode. BRI ISDN commands include: 

□ answerl/2 adds a called number isubaddr ess to be screened. 

□ calling -number adds a calling number included in outgoing calls. 

□ spidl/2 sets a Service Profile ID string calling-number: subaddress. 

□ switch - type selects the interface ISDN switch type. 

□ leased- line sets a BRI interface to support leased lines. 



XSR User's Guide 



195 



ISDN Configuration 



Chapter 9 

Configuring Integrated Services Digital Network (ISDN) 



BRI (Switched) Configuration Model 

Figure 34, shown below, illustrates how Dialer and BRI interfaces are 
configured on the XSR's BRI NIM card as well as how those interfaces 
correlate to dialer and access lists, map classes, and dialer pools. 



Dialer Profile 



Defines the destination 



interface dialer 0 

ip address 1.1.1.1 255.255.255.0 
encapsulation ppp and other protocol 

commands 
dialer string 5551000 class remNodel 
dialer string 5551000 class remNode2 
dialer pool 1 
dialer-group 1 



CO 
X 



map-class dialer 



Dialer List 1 

describes interesting 
packets 



priority 



interface BR1 1/0 

isdn switch-type basic-nil 
isdnspidl 0555100001 5551000 
isdn spid2 0555300001 5553000 
dialer pool-member 1 priority 100 
... more BRI commands 



o 
o 
□_ 

Q 



priority ) 



Access List 



interface dialer 1 

ip address 2.2.2.2 255.255.255.0 
encapsulation ppp and other protocol 

commands 
ppp multilink over up to 4 B channels 
dialer map ip 192.168.1.10 name HOME 

212555756 

dialer pool M 
dialer-group 10 




interface BRI 1/1 

isdn switch-type basic-nil 
isdn spidl 0555200001 5552000 
isdn spid2 0555400001 5554000 
dialer pool-member 1 priority 100 
... more BRI commands 





interface BR1 1/2 

isdn switch-type basic-nil 
isdn spidl 0555500001 5555000 
isdn spid2 0555700001 5557000 
dialer pool-member 1 priority 100 
... more BRI commands 




Figure 34 Switched BRI Configuration Model 
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The following example adds a dialer pool and group, and two phone 
numbers to the called node's Dialer 0 port. It also configures a second dialer 
pool and group, a Multilink PPP line to four B channels on the Dialer 1 
interface, and maps the 192.168.1.10 network and phone number to BRI 
interface 1/0, as well as adds a prioritized pool member and six SPIDs. 
Finally, the example configures two more BRI interfaces with prioritized pool 
members and two SPIDs each. You can add map class, dialer and access list, 
BRI, and other protocol commands not shown in the example. 

XSR (conf ig) #interf ace dialer 0 

XSR(config-if<D0>) #ip address 1.1.1.1 255.255.255.0 
XSR (conf ig-if <D0>) #encapsulation ppp 

XSR (conf ig-if<D0>) #dialer string 5551000 class remNodel 
XSR (conf ig-if <D0>) #dialer string 5551000 class remNode2 
XSR (conf ig-if <D0>) #dialer pool 1 
XSR (conf ig-if <D0>) #dialer -group 1 
XSR (conf ig-if <D0>) #no shutdown 
XSR (conf ig) #interf ace dialer 1 

XSR(conf ig-if<Dl>) #ip address 2.2.2.2 255.255.255.0 
XSR (conf ig-if <D0>) #encapsulation ppp 
XSR (conf ig-if <D0>) #ppp multilink 

XSR (conf ig-if <D0>) ttdialer map ip 192.168.1.10 name HOME 212555756 
XSR (conf ig-if <D0>) #dialer pool M 
XSR (conf ig-if <D0>) #dialer-group 10 
XSR (conf ig-if <D0>) #no shutdown 
XSR (conf ig) #interf ace bri 1/0 

XSR (conf ig-if <BRI-l/0>) #isdn switch-type basic-nil 
XSR(config-if<BRI-l/0>) #isdn spidl 0555100001 5551000 
XSR(config-if<BRI-l/0>) #isdn spid2 0555300001 5553000 
XSR (conf ig-if <BRI-l/0>) #dialer pool-member 1 priority 100 
XSR (conf ig-if <BRI-l/0>) #no shutdown 
XSR (conf ig) #interf ace bri 1/1 

XSR (conf ig-if <BRI-1/1>) #isdn switch-type basic-nil 
XSR(config-if<BRI-l/l>) #isdn spidl 0555200001 5552000 
XSR(config-if<BRI-l/l>) #isdn spid2 0555400001 5554000 
XSR (conf ig-if <BRI-1/1>) #dialer pool-member 1 priority 90 
XSR (conf ig-if <BRI-1/1>) #no shutdown 
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XSR (conf ig) #interface bri 1/2 

XSR (conf ig-if <BRI-l/2>) #isdn switch-type basic-nil 
XSR(config-if<BRI-l/2>) #isdn spidl 0555500001 5555000 
XSR(config-if<BRI-l/2>) #isdn spid2 0555700001 5557000 
XSR (conf ig-if <BRI-l/2>) #dialer pool-member 1 priority 80 
XSR (conf ig-if <BRI- 1/2 >) #no shutdown 

For further explanation and more examples of Dialer interface and Multilink 
PPP configuration, refer to "Configuring Dialer Services" on page 135 and 
"Configuring PPP" on page 103. 

PRI Configuration Model 

Figure 35, shown below, configures Dialer and Serial interfaces on the 
XSR's PRI NIM card as well as describes how those interfaces correlate to 
dialer and access lists, map classes, dialer pools, and channel groups. 



XSR 






interface dialer 0 

ip address 111 

encapsulation ppp and other 
comma 

dialer string 5551000 class r 
dialer string 5551000 class r 
dialer pool 1 i 
dialer-group 1 
A 


protocol 
ids 

emNodel 
emNode2 

{ 













priority 



map-class dialer 



Dialer List 1 

describes interesting 
packets A 




Access List 



controller t1 1/0/0 
pri-group 

controller 1/0/0:23 for T1 NIM 
or 

controller 1/0/0:15 for El NIM 

isdn switch-type primary-ni 
isdn bchan-number-order 
dialer pool-member 1 priority 100 
dialer pool-member 1 priority 50 
... more PRI commands 



Figure 35 PRI Configuration Model 
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The following Tl example adds a dialer pool and group, and two dialer strings to 
the node's Dialer 0 port. It also sets all 23 B-channel timeslots, adds two 
prioritized pool members, and maps the Tl NIM card to the 1/0/ 0:23 D-channel 
sub-interface. You can add map class, dialer list and ACL commands not shown. 

XSR (conf ig) #interf ace dialer 0 

XSR(config-if<D0>) #ip address 1.1.1.1 255.255.255.0 
XSR (conf ig-if <D0>) #encapsulation ppp 

XSR (conf ig-if<D0>) #dialer string 17574231234 class rem nodel 

XSR (conf ig-if <D0>) #dialer string 17574235678 class rem node2 

XSR (conf ig-if <D0>) #dialer pool 1 

XSR (conf ig-if <D0>) #dialer-group 1 

XSR (conf ig-if <D0>) #no shutdown 

XSR (conf ig) #controller tl 1/0/0 

XSR (conf ig-controller<Tl-l/0/0>) #pri-group 

XSR (conf ig-controller<Tl-l/0/0>) #no shutdown 

XSR (conf ig) #controller 1/0/0:23 

XSR(config-controller<Tl-l/0/0:23>) # 

XSR (conf ig- control ler<Tl -l/0/0:23>) #isdn switch-type primary-ni 
XSR (conf ig-controller<Tl-l/0/0 : 23>) ttisdn bchan- number -order ascending 
XSR (conf ig- control ler<Tl-l/ 0/0 : 23>) ttdialer pool-member 1 priority 100 
XSR (conf ig-controller<Tl-l/0/0 : 23>) ttdialer pool-member 1 priority 50 

Optionally, the following El commands set the Central Office switch type and 
add prioritized pool members to El 1/0/0:15 D-channel sub-interface: 

XSR (conf ig-controller<El- 0/0 : 15>) #isdn switch-type primary-net5 
XSR (conf ig-controller<El-0/0 : 15>) #isdn bchan -number -order 
XSR (conf ig-controller<El-0/0 : 15>) #no shutdown 

XSR (conf ig-controller<Sl-0/0 : 15>) ttdialer pool-member 1 priority 100 
XSR (conf ig-controller<Sl-0/0 : 15>) ttdialer pool-member 1 priority 50 

Be aware that the isdn bchan -number -order command forces the PRI 
interface to make outgoing calls in ascending or descending order. The 
command is recommended only if your service provider requests it to lessen 
the chance of call collisions. 

The pri -group command enables ISDN and configures all timeslots to map 
to channel groups on the PRI NIM card. 
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Leased-Line Configuration Model 

The BRI Leased Line application supports two basic modes: each B channel is 
routed to a different destination or both B channels are bounded. Only one 
BRI-specific command is needed for this application, leased- line, which 
can be configured at 56, 64, 112, 128, or 144 Kbps. 

m / note 

Be aware that two data streams are supported, one on each B channel, at 
56 and 64 Kbps only, and one data stream is supported over the bounded 
Bl + B2 or B1+B2+D line at 112, 128, or 144 Kbps only 



Figure 36 illustrates how a Leased Line application is configured on the 
XSR's BRI NIM card with either PPP or Frame Relay encapsulation. 



IP 



interface BRI 0/1/1 

leased-line BRI 0/1/1 56 | 64 
leased-line BRI 0/1/1 56 | 64 



interface BRI 0/1/1 

leased-line BRI 1/1 112|128|144 



interface BRI 0/1/1:1 

ip address 1.1.1.2 
255.255.255.0 
encapsulation ppp 

... any serial interface 
command 



interface BRI 0/1/1:2 

ip address 1.1.1.3 
255.255.255.0 
encapsulation FR 

... any serial interface 
command 



interface BRI 0/1/2:1 

ip address 1 .1 .1 .3 255.255.255.0 
encapsulation FR 

... any serial interface command 



B1 



B2 



Leased S/T or U BRI line 



Leased S/T or U BRI line 



Figure 36 BRI Leased Line Application 
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More Configuration Examples 



The following commands, as shown in Figure 36, add two leased lines on BRI 
0//1/1 B-channels 1 and 2 with PPP and Frame Relay encapsulation on 
either line. You can add other serial interface commands as needed. 

XSR(conf ig) #interface bri 0/1/1 

XSR(conf ig-if<BRI-l/l>) #leased-line bri 0/1/1 56 
XSR(conf ig-if<BRI-l/l>) #leased-line bri 0/1/1 56 
XSR (conf ig-if <BRI-1/1>) #no shutdown 
XSR(conf ig) #interface bri 0/1/1:1 

XSR(config-if<BRI-l/l:l>) #ip address 1.1.1.2 255.255.255.0 
XSR (conf ig-if <BRI-1/1 : 1>) #encapsulation ppp 
XSR (conf ig-if <BRI-1/1 : 1>) #no shutdown 
XSR (conf ig#interf ace bri 0/1/1:2 

XSR(config-if<BRI-l/l:2>) #ip address 1.1.1.3 255.255.255.0 
XSR (conf ig-if <BRI-1/1 : 2>) #encapsulation frame relay 

The following commands add a third, bundled B1/B2 line on BRI interface 
0/1/1 and another lease line on BRI channel 0/1/2:1 with Frame Relay 
encapsulation. You can add other serial interface commands as needed. 

XSR (conf ig) #interf ace bri 0/1/1 

XSR(conf ig-if<BRI-l/l>) #leased-line bri 0/1/1 144 
XSR (conf ig-if <BRI-1/1>) #no shutdown 
XSR (conf ig-if ) #interf ace bri 0/1/2:1 

XSR (conf ig-if <BRI-0/l/2 : 1>) #ip address 1.1.1.3 255.255.255.0 
XSR (conf ig-if <BRI-0/l/2 : 1>) #encapsulation frame relay 

More Configuration Examples 

The following configuration examples cover Tl/El, PRI and BRI, and lease- 
line options on the XSR. For more details on Dialer and Multilink PPP 
options, refer to "Configuring Dialer Services" on page 135 and "Configuring 
PPP" on page 103. 

T1 PRI 

The following example configures a PRI connection on a Tl card: 

XSR (conf ig) #controller tl 1/2/3 

XSR (conf ig- control ler<Tl- 2/3 >) #pri -group 

XSR (conf ig- con t roller <T1- 2/3 >) #isdn switch-type primary-ni 
XSR (conf ig-controller<Tl-2/3>) #isdn bchan- number -order descending 
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XSR (conf ig-controller<Tl-2/3>) #isdn calling-number 915086671234 
XSR (conf ig- control ler<Tl- 2/3 >) #no shutdown 

E1 PRI 

The following example configures a PRI connection on an El card: 

XSR (conf ig) #controller el 1/2/2 

XSR (conf ig- control ler<El- 2/2 >) #pri -group 

XSR (conf ig- con t roller <E1- 2/2 >) #isdn switch-type primary-net5 
XSR (conf ig-controller<El-2/2>) ttisdn bchan- number -order descending 
XSR (conf ig-controller<El-2/2>) #isdn no calling -number 
XSR (conf ig- control ler<El- 2/2 >) #no shutdown 

ISDN BRI 

The following example configures a non-leased line BRI connection: 
XSR (conf ig) #interface bri 1/1 

XSR (conf ig-if <BRI-1/1>) #isdn switch-type basic-nil 
XSR(conf ig-if<BRI-l/l>) #isdn spidl 2200555 2200 
XSR(conf ig-if<BRI-l/l>) #isdn spid2 2201555 2201 
XSR (conf ig-if <BRI-1/1>) #no shutdown 

XSR (conf ig-if <BRI-1/1>) #dialer pool-member 1 priority 1 

BRI Leased Line 

The following example configures a leased-line BRI connection: 

XSR (conf ig) #interf ace bri 1/0 
XSR(conf ig-if<BRI-l/0>) #leased-line 64 
XSR(conf ig-if<BRI-l/0>) #leased-line 64 
XSR (conf ig-if <BRI-l/0>) #no shutdown 

BRI Leased PPP 

The following example configures a leased PPP connection on a BRI link: 

XSR (conf ig) #interface bri 1/0:2 

XSR (conf ig-if <BRI-l/0:2>) #no shutdown 

XSR (conf ig-if <BRI-l/0 : 2>) #encapsulation ppp 

XSR(config-if<BRI-l/0:2>)#ip address 10.10.10.11 255.255.255.0 
XSR (conf ig-if <BRI-l/0 : 2>) #ppp keepalive 
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BRI Leased Frame Relay 

The following example configures Frame Relay service over a multipoint 
leased BRI connection. For more information on Frame Relay, refer to 
"Configuring Frame Relay" on page 119. 

XSR (conf ig) #interface bri 1/0:1 

XSR (conf ig-if <BRI-l/0 : 1>) #no shutdown 

XSR (conf ig-if <BRI- 1/0 : 1>) #encapsulation f rame -relay 

XSR (conf ig-if <BRI-l/0 : 1>) #frame-relay lmi-type none 

XSR (conf ig) #interf ace bri 1/0:1.1 multi-point 

XSR(config-if<BRI-l/0:l>) #ip address 2.2.2.2 255.255.255.0 

XSR (conf ig-if <BRI-l/0 : 1>) #frame-relay interf ace-dlci 16 

XSR (conf ig-if <BRI-l/0 : 1-16>) #no shutdown 

ISDN (ITU Standard Q.931) Call Status Cause Codes 

The XSR supports the following Q.931 Cause Codes: 



Table 9 Call Status Cause Codes 



Code 


Cause 


0 


Valid cause code not yet received 


1 


Unallocated (unassigned) number 


2 


No route to specified transit network (WAN) 


3 


No route to destination 


4 


Send special information tone/Channel unacceptable 


5 


Misdialed trunk prefix 


6 


Channel unacceptable 


7 


Call awarded and being delivered in an established channel 


8 


Prefix 0 dialed but not allowed 


9 


Prefix 1 dialed but not allowed 


10 


Prefix 1 dialed but not required 
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Table 9 Call Status Cause Codes (Continued) 



Code 


Cause 


11 


More digits received than allowed, call is proceeding 


16 


Normal call clearing 


17 


User busy 


18 


No user responding 


19 


19 No answer from user 


21 


Call rejected 


22 


Number changed 


23 


Reverse charging rejected 


24 


Call suspended 


25 


Call resumed 


26 


Non-selected user clearing 


27 


Destination out of order 


28 


Invalid number format (incomplete number) 


29 


Facility rejected 


30 


Response to STATUS ENQUIRY 


31 


Normal, unspecified 


33 


Circuit out of order 


34 


No circuit/channel available 


35 


Destination unattainable 


36 


Out of order 


37 


Degraded service 


38 


Network (WAN) out of order 


39 


Transit delay range cannot be achieved 


40 


Throughput range cannot be achieved 
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Table 9 Call Status Cause Codes (Continued) 



Code 


Cause 


41 


Temporary failure 


42 


Switching equipment congestion 


43 


Access information discarded 


44 


Requested circuit channel not available 


45 


Pre-empted 


46 


Precedence call blocked 


47 


Resource unavailable - unspecified 


49 


Quality of service unavailable 


50 


Requested facility not subscribed 


51 


Reverse charging not allowed 


52 


Outgoing calls barred 


53 


Outgoing calls barred within CUG 


54 


Incoming calls barred 


55 


Incoming calls barred within CUG 


56 


Call waiting not subscribed 


57 


Bearer capability not authorized 


58 


Bearer capability not presently available 


63 


Service or option not available, unspecified 


65 


Bearer service not implemented 


66 


Channel type not implemented 


67 


Transit network selection not implemented 


68 


Message not implemented 


69 


Requested facility not implemented 


70 


Only restricted digital information bearer capability is available 
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Table 9 Call Status Cause Codes (Continued) 



Code 


Cause 


79 


Service or option not implemented, unspecified 


81 


Invalid call reference value 


82 


Identified channel does not exist 


83 


A suspended call exists, but this call identity does not 


84 


Call identity in use 


85 


No call suspended 


86 


Call having the requested call identity has been cleared 


87 


Called user not member of CUG 


88 


Incompatible destination 


89 


Non-existent abbreviated address entry 


90 


Destination address missing, and direct call not subscribed 


91 


Invalid transit network selection (national use) 


92 


Invalid facility parameter Mandatory information element is missing 


95 


Invalid message, unspecified 


96 


Mandatory information element is missing 


97 


Message type non-existent or not implemented 


98 


Message not compatible with call state or message type non-existent or not 
implemented 


99 


Information element nonexistent or not implemented 


100 


Invalid information element contents 


101 


Message not compatible with call state 


102 


Recovery on timer expiry 


103 


Parameter non-existent or not implemented - passed on 


111 


Protocol error, unspecified 
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Table 9 Call Status Cause Codes (Continued) 



Code 


Cause 


127 


Internetworking, unspecified 
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Overview 

In a typical network, there are often many users and applications competing 
for limited system and network resources. While resource sharing on a first- 
come, first-serve basis may suffice when your network load is light, access 
can freeze quickly when the network gets congested. Under these conditions, 
a bandwidth-hungry application (large file transfer files, emails) may devour 
most of the network bandwidth, depriving applications that send small-sized 
packets (voice, telnet and other interactive applications) of their fair share of 
bandwidth, and result in long delays causing applications to fail. 

Quality of Service cannot magically provide all applications their requested 
bandwidth, but it can help you identify your mission-critical, high priority 
application traffic and give it preferential treatment (higher priority, higher 
bandwidth or guaranteed bandwidth) relative to the rest of your network 
traffic. In this way, critical applications will work under both normal and 
congested conditions while less important and time-sensitive traffic will 
continue to flow, perhaps at a lower rate than expected. 

To configure QoS properly, you should consider the following: 

□ Know the load on your network to decide if you need QoS processing 

□ Know the programs running on your network to identify vital 
applications that you need to protect, and determine how much 
bandwidth you need to allocate to these applications 

□ Determine how to classify traffic into different classes 

□ Decide which queueing algorithms, congestion mechanisms, and 
traffic options best satisfy your overall applications 

□ Configure the XSR using the above criteria 
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Features 

The XSR's support of QoS module allows you to: 

□ Classify traffic in different traffic flows using user-defined filters 
based on packet headers and payloads 

□ Meter and police traffic flows based on traffic policy 

□ Prioritize time-critical traffic flows and ensure that packets from these 
flows are serviced with bounded delay 

□ Share output bandwidth in a fair manner between the number of 
best-effort traffic flows 

□ Manage queues using two queue management strategies: tail-drop or 
Random Early Detection (RED) 

□ Mark packets from a specific flow with DSCP or IP precedence values 
QoS service on the XSR is proscribed by the following limits: 

□ Traffic policy can be applied to output only 

□ The maximum number of classes allowed is 64 

□ The traffic policer cannot be configured for traffic flows assigned to 
priority queues. Each priority queue is metered and policed by 
default to guarantee it conforms to the scheduled traffic pattern 

□ Priority and bandwidth commands are mutually exclusive; a traffic 
flow is assigned to either queue, not both 

□ Tail-drop (queue -limit) and RED (random- detect) are mutually 
exclusive; a queue is managed by either mechanism, not both 

Mechanisms to Provide QoS 

This following section describes the general mechanisms the XSR employs to 
support Quality of Service. 

Traffic Classification 

Before the XSR can apply QoS to traffic, it must differentiate between types of 
traffic. The process is called Traffic Classification. 
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Mechanisms to Provide QoS 



The following table describes typical traffic classification: 



Table 10 Traffic Classification 



Classification 
Criteria 


Description 


Additional 
Comments 


IP Precedence bits 
in IP header (IP 
only) 


Simple classification for IP packets only. IP Precedence bits reside 
inside the TOS byte of the IPv4 header and are 3-bits long, 
providing up to 8 levels of QoS classes. 


Simple, IP 
traffic only 


DSCP (DiffServ 

Pn/Ho Pf^ini^ Kite in 
UUUc rUllllJ Ullb 111 

IP header (IP only) 


Simple classification for IP packets only. This QoS signaling 
iiitJiiiuu ib Uciiiicu uy lilt; \c \ r unioci v yiuup piuviuiny d 
scalable QoS solution. It is 6-bits long and can provide 64 
different traffic classes. DSCP overlaps with the IP Precedence 
bits in the IP header and can be considered a super set of IP 
Precedence. 


Simple, IP 

UdMIU Ulliy 


Multiple-Field 
Classification 


This classification generally looks at the L3 header (source and 
destination IP addresses), L4 header (TCP/UDP port numbers to 
identify the nature of applications as FTP, Telnet, Web, etc.), and 
in some cases, look at fields beyond the L4 header (e.g., to 
differentiate Web access to certain Web pages from other Web 
accesses), to narrow the classification and choose traffic from a 
particular application. 


Most 
versatile 
but CPU 
intensive. 



The XSR provides a class-based traffic classifier that creates traffic policies 
and attaches them to interfaces, sub-interfaces, and virtual circuits such as 
Frame Relay DLCIs. A traffic policy contains a traffic class and one or more 
QoS features. A traffic class is used to classify traffic, while the QoS features in 
the traffic policy determine how to treat the classified traffic. Traffic policy 
cannot be applied to multilink PPP interfaces at this time. 

A Dialer interface is similar to a virtual interface in that only after it dials on 
a resource from a dialer pool is it able to receive and send data. A policy 
map applied to a dialer interface is automatically pushed to the resource 
(Serial or ISDN interface) that the dialer called on. When the connection is 
cleared, the policy map is automatically removed from the resource. 
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You must perform three steps to configure a class-based classifier: 

1 Define a traffic class with the class-map command. 

2 Create a traffic policy by associating the traffic class with one or more 
QoS features (using the policy-map command). 

3 Attach the traffic policy to the port or DLCI with the service-policy 
command. 

A QoS policy-map for DLCI defines a set of complex rules to identify classes 
of traffic and then applies service policies to them. Use the traffic-class-map to 
group a set of simple rules to form a set of complex rules. You can define 
complex rules with a combination of matching criteria and, at the same time, 
not matching other criteria. 

Describing the Class Map 

The traffic class map builds complex rules with matching criteria. Multiple 
rules can be specified by a given traffic class-map using the class -map 
command, but all rules in the given class map must be configured to use the 
same matching criteria: 

□ match-any 

□ match-all 

The following traffic class map defines the match-all class-map abc. A packet 
that satisfies the criteria defined in access-group 2 and has a DSCP value set 
to 32 is considered a part of this traffic class. In a match-all class-map all 
criteria must be met in order for the packet to be assigned to the class. 

XSR (conf ig) #access-list 2 permit 15.15.15.0 0.0.0.255 

XSR (conf ig) #class-map match-all abc 

XSR (conf ig-cmap<abc>) #match access -group 2 

XSR (conf ig-cmap<abc>) #match ip dscp 32 

In a match-any class-map, one or more criteria of the class-map must be met in 
order for packets to be assigned to the class. For example, if class-map ABC 
were a match-any class-map, packets arriving with a source address of 
15.15.15.3, with Layer 3 protocol IP and DSCP value of 12 assigned, would be 
classified as class ABC since it matches access-list 2. 
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Describing the Policy Map 

The policy statement in a QoS policy-map specifies how traffic defined by the 
traffic class-map will be treated. Each class in policy-map has to be assigned 
to one of the two types of queues: CBWFQ or Priority Queue. This includes 
specifying the following: 

□ The bandwidth command assigns traffic from this class to a Class- Based 
Weight Fair Queue (CBWFQ) with the specified bandwidth. A CBWFQ 
shares the output link with other CBWFQs on the same link in 
proportion to its specified bandwidth or weight. During congestion, 
queues are serviced (assigned bandwidth) in proportion to their weight. 
When uncongested, a queue can borrow bandwidth from other queues. 

□ The priority command assigns traffic from this class a Priority 
Queue (PQ) and sets the parameter for the queue. Priority queues 
provide guaranteed bandwidth - they always receive the bandwidth 
requested. Priority class is not allowed to send more than its 
guaranteed bandwidth and excess traffic is discarded. Unused 
priority bandwidth is picked up by the class-default class. 

For classes that are assigned to CBWFQ you can control the maximum rate of 
traffic sent or received on a port as follows: 

□ The police command controls traffic received by a queue by 
defining the action taken for packets that conform or exceed the 
specified rate. You may drop the packet, change its IP precedence or 
DSCP setting, or forward it without modification. 

Both CBWFQ and Priority Queues can control queue size and the type of 
congestion avoidance mechanism, as well as mark packets as follows: 

□ The set ip precedence, set ip dscp commands mark a packet by 
setting the IP precedence or DSCP field. The Differentiated Services 
Field is defined in RFCs-2474 and 2475. 

□ The queue -limit command specifies or modifies the maximum 
number of packets the queue can hold before tail drop for TCP/IP 
traffic for a class policy configured in a policy map. 

□ The random -detect command sets Random Early Detect (RED), a 
congestion avoidance mechanism that slows traffic by randomly 
dropping packets when congestion exists. 

Traffic not assigned to a class in the policy-map is assigned to class-default 
which is always created and assigned as a CBWFQ. Bandwidth for the class- 
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default comprises whatever remains after all other classes are served. You can 
configure class-default as any other CBWFQ, except that you cannot assign 
bandwidth to it. 

Queuing and Services 

Once traffic has been classified, it is dropped into different queues so that 
each class of traffic can be treated differently (priority, bandwidth etc.). The 
following describes two queue types used in the XSR: Class Based Weight 
Fair Queuing and Priority Queuing. They are mutually exclusive - only one 
type of queue may be applied to one class. But, they may be mixed in a 
policy-map when applied to different classes. 

Describing Class-Based Weight Fair Queuing 

The configured bandwidth of a class is the bandwidth delivered to the class 
during congestion. The higher the bandwidth, the more likely the packet is 
being transmitted under congested conditions. If there is no data on a 
particular queue, then its share of the bandwidth will be divided and shared 
among the active queues in proportion to their specified bandwidth. 

CBWFQ specifies the exact amount of bandwidth to allocate for a specific 
class, or queue, of traffic. Taking into account available bandwidth on the 
interface, you can configure up to 64 classes and control distribution among 
them. If excess bandwidth is available, it is divided among other CBWFQs in 
proportion to their configured band widths. 

When bandwidth is specified as an absolute number, it is used to calculate the 
weight of the class. In such a case, the sum of bandwidth for all classes, 
including priority classes, should not exceed the link bandwidth otherwise 
the bandwidth for the default class will be zero causing a traffic blockage and 
packet pileup in the queue. 



For each policy-map, only one type of bandwidth, percentage or absolute 
bandwidth, can be used for all the CBWFQ classes inside the policy-map. 




NOTE 
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Configuring CBWFQ 

CBWFQ is configured using the bandwidth command. It provides a minimum 
bandwidth guarantee during congestion. For example, policy-map keyser 
guarantees 30 percent of the bandwidth to class sosay and 60 percent of the 
bandwidth to class intrigue. If one class uses less of the requested share of 
bandwidth, the excess bandwidth may be used by the other class. 

XSR (conf ig) #policy-map keyser 

XSR (conf ig-pmap<keyser>) #class sosay 

XSR (conf ig-pmap-c<sosay>) #bandwidth percent 30 

XSR (conf ig-pmap<keyser>) #class intrigue 

XSR (conf ig-pmap-c<intrigue>) #bandwidth percent 60 

Describing Priority Queues 

Priority Queues (PQ) extend absolute (strict) priority to certain traffic. Higher 
priority packets are sent before lower priority packets, and lower priority 
packets are sent before any non-priority packets. 

Priority queuing ensures that applications which cannot tolerate much delay 
(e.g., voice and video traffic) are serviced before non-time critical applications 
(e.g., FTP). 

Traffic assigned to priority queues is rate-limited so the queue's presence 
would not "starve" low priority packets and fair queues. The XSR supports 
up to four priority queues per interface, labeled high, medium, low, and normal. 
They are characterized by the following rules: 

□ High priority queues are emptied before low priority queues. 

□ PQ bandwidth is controlled using a traffic policer to rate-limit it 

^ NOTE 



If priority queues are configured to take up almost the entire bandwidth 
of the interface or PVC, CBWFQ and control packets will get no actual 
bandwidth and may be blocked. 
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Configuring Priority Queues 

The priority command configures priority queuing for certain packets 
based on the traffic class. When you specify priority (using the following 
commands) for a class, it takes a bandwidth argument affording maximum 
bandwidth. The following commands configure priority queuing: 

□ policy-map policy-name 

□ class class-name 

□ priority priority- level kbps [burst- size] 

Be aware that bandwidth guarantees come into play when an interface is 
congested, at which time traffic class guarantees bandwidth equal to the 
specified rate. The priority command implements a maximum bandwidth 
guarantee. If the priority class does not use its bandwidth, the excess 
bandwidth may be used by CBWFQ. A rule of thumb for configuring PQs is 
to assign time-sensitive traffic (voice and video) to PQs and other types (e.g., 
Telnet) to fair queues. Any traffic you do not specially assign (e.g., Email) is 
automatically directed to the class-default queue. All (100%) of your traffic 
should not be assigned to PQs - a smaller percentage of lower priority traffic 
should be designated for fair queues of left unassigned for the default queue. 

Internally, the priority queue uses a Token Bucket that measures the offered 
load and ensures that the traffic stream conforms to the configured rate. Only 
traffic that conforms to the token bucket is guaranteed low latency. Any 
excess traffic is dropped even when the link is not congested. 

The priority command also sets burst size, a network value used to 
accommodate temporary bursts of traffic. The default burst value, which is 
computed as 1 second of traffic at the configured bandwidth rate, is used when 
the burst argument is not specified. 

The XSR allows the priority queue size to grow as much as allowed by the 
traffic meter. 

The following example illustrates priority configuration options and how 
they are invoked on a Frame Relay port. Begin by creating traffic class frost: 

XSR (conf ig) #c lass -map frost 

XSR (conf ig-cmap<f rost>) #match access-group 10 
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Assign the class frost to the priority queue: 

XSR (conf ig) #policy-map framel 

XSR (conf ig-pmap< framel >) #class frost 

XSR (conf ig-pmap-c<f rost>) #priority high 20 

XSR (conf ig-pmap-c<f rost>) # queue -limit 3 0 

Describing Traffic Policing 

While it is possible to precisely control the output rate of all traffic using 
CBWFQ and priority queues with maximum link bandwidth, practically 
speaking, this is rarely done. Typically, you identify certain critical 
applications, assign QoS values and bandwidth to them, and let the 
remainder of traffic take whatever bandwidth is left. 

The XSR's implementation of traffic policing provides this benefit: 

□ Packet marking through IP precedence or DSCP value setting - 
Packet marking partitions your network into multiple priority levels. 

Configuring Traffic Policing 

To successfully configure Traffic Policing, you must create a traffic class and 
attach the traffic policy to an interface or DLCI. The police command 
specifies the following options: 

□ Bandwidth, burst and excess burst values 

□ Action to take for traffic that conforms or exceeds the specified rate 

This is how the policer works. It maintains two token buckets, one holding 
tokens for normal burst and the other for excess burst. The policing algorithm 
handles token refilling and burst checking. 

Token buckets are refilled every time a new packet arrives. The specified 
bandwidth and the interval between the arrival time of the new packet and 
that of the previous packet are used to calculate the number of tokens to refill 
the buckets. The formula is as follows: 

Refill Token Bytes = (Bandwidth * Interval) / 8 
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The bucket for holding tokens for normal burst is refilled first. If the 
calculated Refill Token Bytes is enough to top the bucket for normal burst to the 
burst value specified, the remainder of Refill Token Bytes are added to the 
bucket for excess burst (refer to the formula below). Also, the number of 
tokens for excess burst is also limited by the excess burst value specified in 
the police command. 

The packet length is checked against the token bytes available in the two 
buckets. If the number of token bytes in the bucket for normal burst is larger 
than the packet length, the conform-action applies to this packet; if the token 
bytes for normal burst is not enough, but the number of token bytes for excess 
burst is larger than the packet length, the exceed-action applies to this packet; if 
neither of the token bytes for normal burst or excess burst is enough, the 
violate-action applies to this packet. 

In the following example, traffic policing is configured with an average rate of 
8,000 bits per second, normal burst size of 2,000 bytes, and excess burst size of 
4,000 bytes. Packets entering serial interface 1/0 are analyzed as to whether 
packets conform, exceed, or violate specified parameters. Packets which 
conform to parameters are sent, those which exceed parameters are set to a 
DSCP value of 43 and sent, and those which violate parameters are dropped. 

XSR (conf ig) #class-map the_heat 

XSR (conf ig-cmap<the_heat>) #match access -group 2 

XSR (conf ig) #policy-map turf 

XSR (conf ig-pmap<turf >) #class the_heat 

XSR (conf ig-pmap-c<the_heat>) #bandwidth percent 30 

XSR (conf ig-pmap-c<the_heat>) #police 8000 2000 4000 conform-action 
transmit exceed-action set-dscp- transmit 43 violate-action drop 

XSR (conf ig) #interf ace serial 1/0 

XSR (conf ig- if <S1/ 0>) # service -policy output turf 
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Congestion Control & Avoidance 

Describing Queue Size Control (Drop Tail) 

By using delay control and congestion avoidance, you can control the number of 
queued up packets. If the outgoing queue is empty when a packet is ready to be 
sent, the packet can be forwarded immediately to the line with minimal delay 

But, if there are 20 queued packets in the outgoing queue when the packet 
arrives, the new packet must wait until the 20 queued packets are sent before 
it can be sent. 

Depending on the average packet size of the queued packets and the speed of 
the link, this last packet could be delayed considerably. When the queue limit 
is reached no new arriving packets are accepted in the queue and are 
dropped. The limit of the queue is set by the queue -limit command as 
shown in the following example: 

XSR (conf ig) #policy-map droptail 

XSR (conf ig-pmap<droptail>) #class the_heat 

XSR (conf ig-pmap-c<the_heat>) #queue- limit 50 

Describing Random Early Detection 

Random Early Detection (RED) is a congestion avoidance mechanism for 
adaptive applications (e.g., TCP/IP) that adjusts bandwidth usage of the XSR 
based on network conditions. TCP/IP uses a slow-start feature that initially 
sends a few packets to test network conditions. If the acknowledgement 
returns indicating no packet loss, TCP considers the network capable of 
handling more traffic and increases its output rate. The protocol continues to 
do so until it detects any packets dropped and not delivered, at which point it 
considers the network congested and begins cutting back the output rate. 

Because of TCP's slow-start/ fast-drop-off behavior when dealing with 
congestion, the protocol's performance is choppy when the node/ network is 
heavily loaded and the network does not assert congestion avoidance. This 
occurs because when the node is congested and the outgoing queue fills up, 
subsequent packets (very likely from multiple TCP sessions) are dropped, and 
these in turn cause corresponding TCP sessions to dramatically cut output. 
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After a short delay, all sessions try to ramp up using slow-start in a process 
called Global Synchronization. The queue grows, congestion and packet 
drops recur, and undesirable global synchronization repeats. The end result is 
a distinctive "peak and trough" traffic pattern where the outgoing queue is 
full just before packets are dropped, delay throughout the network is high 
and varies by large margins. 

RED attempts to avoid congestion by proactively dropping packets randomly 
at an early sign of congestion (when the queue grows above a certain 
threshold). Because packets are dropped randomly, all TCP/IP sessions will 
be affected eventually and the treatment made fair to all sessions. 

By dropping packets early - before it reaches its queue limit - RED starts to 
"throttle" the traffic source before the queue grows too large. It helps limit 
delay, which is proportional to the number of packets in the queue, and avoid 
queue overflow and global TCP synchronization. 

The random -detect command includes three parameters to configure RED 
for a queue: minimum threshold (MinThres), maximum threshold (MaxThres) 
and maximum drop probability (MaxProb). The drop probability of a packet is 
based on the average queue size and the three parameters mentioned earlier. 
The calculation of the drop probability is pictured below. 
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Figure 37 RED Drop Probability Calculation 
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In the following example, class bus has a minimum threshold of 460. RED will 
start to randomly (with a probability between 0 and 1/10) discard packets 
when its queue grows over 460 packets. It will start to discard each packet 
when the queue holds more than 550 packets. 

i NOTE 

Drop Tail and RED cannot be used on the same queue at the same time. - 
queue-limit and random-detect are mutually exclusive. If random-detect is set on 
a queue, queue-limit cannot be set on the same queue until RED is removed. 



XSR (conf ig) #policy-map ppwe 

XSR (conf ig-pmap<ppwe>) #class voip 

XSR (conf ig-pmap-c<voip>) #priority high 64 1000 

XSR (conf ig-pmap<ppwe>) #class bus 

XSR (conf ig-pmap-c<bus>) #bandwidth 168 

XSR (conf ig-pmap-c<bus>) # random -detect 460 550 10 

Per Interface Configuration 

QoS can be configured on both LAN and WAN interfaces. It can be enabled 
on Frame Relay and PPP interfaces, and on a sub interface (Frame Relay 
only). The following table illustrates the options: 



Table 11 Configuration Options by LAN/WAN Interface 
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Suggestions for Using QoS on the XSR 

The XSR supports QoS on all interfaces (FastEthernet/ GigabitEthernet, Serial, 
and Frame Relay DLCI). But, you should enable QoS only on the data path 
that actually requires it (generally on lower speed Frame Relay and PPP 
interfaces) because QoS is fairly processor intensive and may adversely 
impact router performance. 

In a typical XSR environment, QoS may be enabled on the WAN link. The 
following lists two configuration scenarios: 

□ A standard office IP application, with no multi-media programs: 

- Enable PQ or CBWFQ 

□ A complex office application, with multi-media applications: 

- Use high Priority Queue for VoIP traffic with a cap on bandwidth 
it may consume 

- Use CBWFQ queue for interactive traffic - Telnet, Web access 

- Use CBWFQ with RED for remaining traffic 

Additionally, if the WAN link is running Frame Relay, you may also enable 
generic traffic shaping on Frame Relay to specify the Committed Information 
Rate (CIR), FECN and BECN options to control link throughput. 

Configuring QoS on an Interface 

The following example configures Classl with these characteristics: a 
minimum of 200 Kbps of bandwidth are expected to be delivered to this class 
in the event of congestion, and the queue reserved for this class can enqueue 
40 packets before tail drop is employed to handle additional packets. 

Class2 is specified with these characteristics: a minimum of 300 Kbps of 
bandwidth are expected to be delivered to this class in the event of 
congestion. For congestion avoidance, RED packet drop is used, not tail drop. 
The default class is configured with a maximum of 20 packets per queue 
which are enqueued before tail drop is used to handle additional packets. 

Begin by creating Classl and Class2 and matching their respective parameters: 
XSR (conf ig) #c lass -map classl 

XSR (conf ig-cmap<classl) #match access-group 136 
XSR (conf ig) #class-map class2 
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XSR (conf ig-cmap<class2>) #match ip precedence 2 

Create the policy map: 

XSR (conf ig) #policy-map policyl 

XSR (conf ig-pmap-policyl>) #class classl 

XSR (conf ig-pmap-c<classl>) #bandwidth 200 

XSR (conf ig-pmap-c<classl>) #queue- limit 40 

XSR (conf ig-pmap<policyl>) #class class2 

XSR (conf ig-pmap-c<class2>) #bandwidth 3 00 

XSR (conf ig-pmap-c<c las s2 >) # random -detect 34 56 3 

XSR (conf ig-pmap<policyl>) #class class -default 

XSR (conf ig-pmap-c<class-def ault>) #queue- limit 2 0 

Apply the configuration to the interface: 
XSR (conf ig) #interf ace serial 1/1 

XSR (conf ig-if <S1/1>) #service -policy output policyl 



Configuring QoS for Frame Relay 

The following example sets Serial interface 1/1 for Frame Relay with one 
DLCI (100) which will support three types of traffic: voice that is assigned to a 
priority queue with a bandwidth of 20 kbps, FTP that is assigned to fair queue 
with 50 percent of the remaining bandwidth, and Classl that is assigned to 
class-default (and gets the other 50 percent). DLCI 100 sets CIR at 64 kbps (the 
sum of all PQs and classes should not exceed the CIR of the DLCI). 

When the connection is congested, priority traffic will get its bandwidth share 
(smaller than the DLCI CIR) while all other classes share the remaining 
bandwidth proportional to what was requested. Voice is rate limited to 
20 Kbps and the interval over which it is enforced is equivalent to 
burst/bandwidth size (2500 bytes/20 Kbps). 

If no burst size is set, default burst size is used. Packets exceeding 20 Kbps are 
dropped. Classl and FTP are served after voice gets its share, but split the 
remaining bandwidth equally. 



XSR User's Guide 



223 



Configuring QoS for Frame Relay 



Chapter 10 
Configuring Quality of Service 



When there is no congestion each traffic class can use as much bandwidth as 
is available, except the voice which is priority class and is rate-limited to a 
maximum of 20 Kbps. BECN will adoptively reduce the CIR of the DLCI but 
does not influence the parameters of the policy-map framel. 

Begin by creating three ACLs to define traffic classes: 

XSR (conf ig) #access-list 101 permit udp 192.168.1.0 0.0.0.255 any 
eq 3 000 

XSR (conf ig) #access-list 102 permit tcp 192.168.1.0 0.0.0.255 any 
eq 3000 

XSR (conf ig) #access-list 103 permit ip any any 

Create classification maps using a combination of ACLs or IP DSCP or 
precedence bits to classify packets: 

XSR (conf ig) #class-map voice 

XSR (conf ig-cmap<voice>) #match access-group 101 
XSR (conf ig) #class-map ftp 

XSR (conf ig-cmap<ftp>) #match access-group 102 

XSR (conf ig-cmap<ftp>) #match ip dscp 18 

XSR (conf ig-cmap<ftp>) #match ip dscp 20 

XSR (conf ig) #class-map match-any class-1 

XSR (conf ig-cmap<classl>) #match access-group 103 

Create a policy map consisting of one or more traffic classes and specify QoS 
characteristics for each traffic class: 

XSR (conf ig) #policy-map framel 

XSR (conf ig-pmap< framel >) #class voice 

XSR (conf ig-pmap-c<voice>) #priority high 20 2500 

XSR (conf ig-pmap-c<voice>) #queue- limit 32 

XSR (conf ig-pmap-c<voice>) #set ip dscp 46 

XSR (conf ig-pmap< framel >) #class ftp 

XSR (conf ig-pmap-c<f ramel>) #bandwidth percent 50 

XSR (conf ig-pmap-c<f ramel>) #police 30000 3000 6000 conform- 

action set-dscp- transmit 10 exceed-action set-dscp- transmit 12 

violate-action set-dscp- transmit 14 

XSR (conf ig-pmap-c<f ramel>) #random-detect 20 35 250 
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Configure map class parameters and apply the policy to the ports: 

XSR (conf ig) #map-class frame-relay cc 

XSR (conf ig-map-class<cc>) #f rame-relay cir 64000 

XSR (conf ig-map-class<cc>) #f rame-relay adaptive- shaping been 

XSR (conf ig-map-class<cc>) #f rame-relay be 8000 

XSR (conf ig-map-class<cc>) #f rame-relay be 16000 

XSR (conf ig-map-class<cc>) #service-policy out framel 

XSR (conf ig) #interf ace serial 1/1 
XSR (conf ig-if <S1/1>) #encapsulation f rame-relay 
XSR (conf ig<Sl/l>) #f rame-relay traffic-shaping 
XSR (conf ig<Sl/l>) #no shutdown 

XSR (conf ig) #interf ace serial 1/1.1 point-to-point 
XSR (conf ig-subif <S1/1 . 1>) #f rame-relay interf ace-dlci 100 
XSR(config-fr-dlci<Sl/l.l-100>) #frame-relay class cc 
XSR(config-fr-dlci<Sl/l.l-100>) #ip address 10.10.10.2 255.255.255.0 
XSR (conf ig-f r-dlci<Sl/l . 1-100>) #no shutdown 
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Network 

VPN Overview 

As it is most commonly defined, a Virtual Private Network (VPN) allows two 
or more private networks to be connected over a publicly accessed network. 
VPNs share some similarities with Wide Area Networks (WAN), but the key 
feature of VPNs is their use of the Internet rather than reliance on expensive, 
private leased lines. VPNs boast tighter security and encryption features as a 
private network, while taking advantage of the economies of scale and 
remote accessibility of large public networks. 

Internet Security Issues 

All communication over the Internet uses the Transmission Control 
Protocol/Internet Protocol (TCP/IP) or User Datagram Protocol (UDP). They 
convey packets from one computer to another through a variety of intermediate 
computers and separate networks before they reach their destination. 

The great flexibility of TCP/IP has led to its worldwide acceptance as the 
basic Internet and intranet communications protocol. But, the fact that 
TCP/IP allows traffic to pass through intermediate computers allows third 
parties to interfere with communications in the following ways: 

□ Eavesdropping - Information remains intact, but its privacy is 
compromised. For example, someone could learn your credit card 
number, record a sensitive conversation, or intercept classified data. 

□ Tampering - Information in transit is changed or replaced and then sent 
on to the recipient. For example, someone could alter an order for 
goods or change a person's resume. 
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□ Impersonation - Information passes to a person who poses as the 
intended recipient. Impersonation can take two forms: 

- Spoofing - A person can pretend to be someone else. For example, 
a person can pretend to have the email address jdoe@acme . com, 
or a computer can identify itself as a site called www. acme . com 
when it is not. This type of impersonation is known as spoofing. 

- Misrepresentation - A person or organization can misrepresent 
itself. For example, suppose the site www. acme . com pretends to be 
a furniture store when it is really just a site that takes credit-card 
payments but never sends any goods. 

Normally, users of the many cooperating computers that make up the 
Internet or other networks don't monitor or interfere with the network traffic 
that continuously passes through their machines. However, many sensitive 
personal and business communications over the Internet require precautions 
that address the threats listed above. Fortunately, a set of well-established 
techniques and standards aggregated under Internet Protocol Security 
(IPSec)/ Internet Key Exchange (IKE) and the Public-Key Infrastructure 
protocol (PKI) make it relatively easy to take such precautions. 

The combined features of the above protocols facilitate the following tasks: 

□ Encryption and decryption promote confidentiality by allowing two 
communicating parties to disguise information they share. The sender 
encrypts, or scrambles, data before sending it. The receiver decrypts, or 
unscrambles, the data after receiving it. While in transit, the encrypted 
information is unintelligible to an intruder. 

□ Tamper detection ensure data integrity by permitting the recipient of 
data to verify that it has not been modified in transit. Any attempt to 
modify data or substitute a false message for a legitimate one will be 
detected. A hash value is calculated by the sender every time data is 
sent, and calculated when data is received, and both values are 
compared. 

□ Authentication allows the recipient of information to determine its 
origin — that is, to confirm the sender's identity by digitally signing a 
message or by applying the challenge-response method. 

□ Nonrepudiation prevents the sender of information from claiming at a 
later date that the information was never sent. 

A later section of this chapter details the XSR's security implementation. 
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How a Virtual Private Network Works 

VPNs provide an advanced combination of tunneling, encryption, 
authentication and access control technologies and services to carry traffic 
over the Internet, a managed IP network or a provider's backbone. 

Traffic reaches these backbones using any combination of access technologies, 
including Ethernet, Tl, Frame Relay, ISDN, or simple dial access. VPNs use 
familiar networking technology and protocols. The client sends a stream of 
encrypted packets to a remote server or router, except instead of going across 
a dedicated line (as in the case of WANs), the packets traverse a tunnel over a 
shared network. 

The initial idea behind using this method was for a company to reduce its 
recurring telecommunications charges that are shouldered when connecting 
remote users and branch offices to resources at a firm's headquarters. 

Using this VPN model, packets headed toward the remote network will reach 
a tunnel initiating device, which can be anything from an extranet router to a 
laptop PC with VPN-enabled dial-up software. The tunnel initiator 
communicates with a VPN terminator, or a tunnel switch, to agree on an 
encryption scheme. The tunnel initiator then encrypts the package for 
security before transmitting to the terminator, which decrypts the packet and 
delivers it to the appropriate destination on the network. 

The XSR provides Remote Access support for the connection of remote clients 
and gateways in a topology where PPTP or L2TP protocols are employed. The 
XSR also provides Site-to-Site tunnel support in a topology where routers 
occupy each end of a connection. Site-to-site tunnels, also known as peer-to- 
peer tunnels, employ IPSec as the main security provider. 

The XSR's site-to-site connectivity allows a branch office to divest multiple 
private links and move traffic over a single Internet connection. Since many 
sites use multiple lines, this can be a very useful application, and it can be 
deployed without adding additional equipment or software. 

The XSR supports 50 site-to-site tunnels or remote access clients with 32- 
Mbytes of SDRAM DIMM installed and 200 tunnels /clients when upgraded 
with the 64-Mbyte SDRAM DIMM. 
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Ensuring VPN Security with IPSec/IKE 

The key word in Virtual Private Networks is private. To ensure the security of 
sensitive corporate data, the XSR relies chiefly on IPSec, the standard 
framework of security protocols. IPSec is not a single protocol but a suite of 
protocols providing data integrity, authentication and privacy. 

Since IPSec is the standard security protocol, the XSR can be used to establish 
IPSec connections with third-node devices including routers as well as PCs. 
An IPSec tunnel basically acts as the network layer protecting all data packets 
that pass through, regardless of the application or device. 

The XSR makes it possible to control the type of traffic sent over a VPN by 
allowing you to define group-based filters (Access Control Lists) which 
control IP address and protocol/ port services allowed through the tunnel. An 
IPSec-based VPN also permits you to define a list of specific networks and 
applications to which traffic can be passed. 

Central to IPSec is the concept of the Security Association (SA). A primary 
role of IKE is to establish and maintain SAs by its use of the IP Authentication 
Header (AH) or Encapsulating Security Pay load (ESP). An SA is a uni- 
directional logical connection between two communicating IP endpoints that 
applies security to the traffic carried by it using the AH or ESP features listed 
in a transform-set (described below). 

The endpoint of an SA can be an IP client (host) or IP security gateway. 
Providing security for the more typical scenario of bi-directional 
communication between two endpoints requires the establishment of two 
SAs (one in each direction). An SA is uniquely identified by the following: 

□ A 32-bit identifier of the connection 

□ The IP destination address 

□ A security protocol identifier (AH or ESP) 

The IP Authentication Header (AH), defined in RFC-2402, checks for data 
integrity, data origin authentication, and replay on IP packets using HMAC 
with MD5 (RFC-2403), or HMAC with SHA-1 (RFC-2404). 



230 



XSR User's Guide 



Chapter 11 

Configuring the Virtual Private Network 



Ensuring VPN Security with IPSec/IKE 



The IP Encapsulating Security Payload (ESP), described in RFC-2406, 
performs confidentiality in addition to integrity and authentication checks, 
but it does not check the integrity of the IP header. As in AH, ESP uses HMAC 
with MD5 or SHA-1 authentication (RFC-2403/2404); privacy is provided 
using DES-CBC (RFC-2405), 3DES or AES encryption. 

Two types of modes are defined in IPSec, tunnel and transport. At the packet 
level, transport mode leaves the original IP header intact and inserts AH or 
ESP headers after the original IP header as shown in Figure 38 below. 



Original packet 



After processing 



IP 



data 



Can be encrypted 



Figure 38 Transport Mode Processing 



Tunnel mode adds a new IP header and encapsulates the original IP packet as 
shown in Figure 39 below. 



Original packet |p 



After processing 




Can be encrypted 



Figure 39 Tunnel Mode Processing 



As shown above, AH authenticates the entire packet transmitted on the 
network whereas ESP only covers a portion of the packet transmitted (the 
higher layer data in transport mode and the entire original packet in tunnel 
mode). The ramifications of this difference in the scope between ESP and AH 
are significant. 
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Using IPSec along with Network Address Translation (NAT) might be 
problematic because while AH is used to ensure that the packet header is not 
changed during transmission, NAT does the opposite - it changes the IP or 
layer 4 (UDP or TCP) header. AH cannot be used when NAT must be crossed 
to reach the other end of the tunnel. When only ESP is used, the XSR 
automatically adds the UDP header which is required by NAT to operate 
properly when an unroutable address (NAT traffic) is detected between 
tunnel endpoints. 

Arguably the most vital component of IPSec/IKE is the establishment of SAs 
and key management. Although these tasks can be done manually, the 
XSR deploys IPSec through a scalable, automated SA/key management 
scheme known as the Internet Key Exchange (IKE), defined in RFC-2409. This 
algorithm is the default automated key management, dynamic SA-creating 
protocol for IPSec. 

The XSR supports a global ceiling of 150 ISAKMP and 300 IPSec SAs with the 
standard 32-Mbyte memory installed and 600 ISAKMP/ 1200 IPSec SAs with 
the 64-Mbyte memory upgrade installed. 

Defining VPN Encryption 

To ensure that the VPN is secure, limiting user access is only one piece of the 
puzzle; once the user is authenticated, the data itself needs to be protected as 
well. Without a mechanism to provide data privacy, information flowing 
through the channel will be transmitted in clear text, which can easily be 
viewed or stolen with a packet sniffer. VPNs use some kind of cryptosystem 
to scramble data into cipher text, which is then decrypted by the recipient. 

The type of encryption available is highly varied but there are two basic 
cryptographic systems: symmetric and asymmetric. Symmetric cryptography 
tends to be much faster to deploy, are commonly used to exchange large 
volumes of data between two parties who know each other, and use the same 
private key to encrypt and decrypt data. 

Asymmetric systems (public-key) are more complex and require a pair of 
mathematically related keys - one public and one private (known only to the 
recipient). This method is often used for smaller, more sensitive packets of 
data, or during the authentication process. 



232 



XSR User's Guide 



Chapter 11 

Configuring the Virtual Private Network 



Describing Public-Key Infrastructure (PKI) 



As a general rule, longer encryption keys are the strongest. The bit length of 
the algorithm determines the amount of effort required to crack the system 
using a brute force attack, where computers are combined to calculate all the 
possible key permutations. The XSR offers several encryption schemes: 

□ Data Encryption Standard (DES): a 20-year old, thoroughly tested system 
that uses a complex symmetric algorithm, with a 56-bit key, although it 
is considered less secure than recent systems. 

□ Triple DES (3DES): uses three DES passes and an effective key length of 
168 bits, thus strengthening security. 

□ Diffie-Hellman: the first public-key cryptosystem, is used to generate 
asymmetric (secret) keys, not encrypt and decrypt messages. 

□ Advanced Encryption Standard (AES): the anticipated replacement for 
DES, supports a 128-bit block cipher using a 128-, 192-, or 256-bit key. 

□ RSA signatures: an asymmetric public-key cryptosystem used for 
authentication by creating a digital signature. 

Describing Public-Key Infrastructure (PKI) 

PKI is a scalable platform for secure user authentication, data confidentiality, 
integrity, and non-repudiation. PKI can be applied to allow users to use 
insecure networks in a secure and private way. PKI relies on the use of public 
key cryptography, digital certificates, and a public-private key pair. 

Digital Signatures 

Encryption and decryption address eavesdropping, one of the three Internet 
security issues mentioned at the beginning of this chapter. But encryption and 
decryption, by themselves, do not address tampering and impersonation. 

Tamper detection and related authentication techniques rely on a 
mathematical function called a one-way hash (also called a message digest). A 
one-way hash is a number of fixed length with the following characteristics: 

□ The hash value is unique for the hashed data. Any change in the data, 
even deleting or altering a single character, results in a different value. 

□ The content of the hashed data cannot, for all practical purposes, be 
deduced from the hash - which is why it is called one-way. 
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It is possible to use your private key for encryption and public key for 
decryption. Although this is not desirable when you are encrypting sensitive 
data, it is a crucial part of digitally signing any data. Instead of encrypting the 
data itself, the signing software creates a one-way hash of the data, then uses 
your private key to encrypt the hash. The encrypted hash, along with other 
information, such as the hashing algorithm, is known as a digital signature. 

Certificates 

A certificate is an electronic document used to identify an individual, server, 
company, or some other entity and to associate that identity with a public key. 
Like a driver's license, a passport, or other personal IDs, a certificate provides 
proof of a person's identity. PKI uses certificates to address the problem of 
impersonation. Certificates are similar to these familiar forms of ID. 

Certificate Authorities (CAs) validate identities and issue certificates. They 
can be either independent third parties or organizations running their own 
certificate-issuing server software. At this time, the XSR supports the 
Microsoft CA. 

The methods used to validate an identity vary depending on the policies of a 
given CA - just as the methods to validate other forms of identification vary 
depending on who is issuing the ID and the purpose for which it will be used. 
In general, before issuing a certificate, the CA must use its published 
verification procedures for that type of certificate to ensure that an entity 
requesting a certificate is in fact who it claims to be. 

The certificate issued by the CA binds a particular public key to the name of 
the entity the certificate identifies (such as an employee or server name). 
Certificates help prevent the use of fake public keys for impersonation. Only 
the public key certified by the certificate will work with the corresponding 
private key possessed by the entity identified by the certificate. 

In addition to a public key, a certificate always includes the name of the entity 
it identifies, an expiration date, the name of the CA that issued the certificate, 
a serial number, and other data. Most importantly, a certificate always 
includes the digital signature of the issuing CA. The CA's digital signature 
allows the certificate to function as a letter of introduction for users who know 
and trust the CA but don't know the entity identified by the certificate. 
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Machine Certificates for the XSR 

Certificates are used by the IKE subsystem to establish SAs for IPSec 
tunneling. Key information in the certificates is used to identify other IPSec 
clients to the XSR and vice versa. In order to utilize certificates on the XSR you 
must manually collect the certificates for one or more CAs (depending on 
your configuration) and enroll a certificate for the router. Certificates for CAs 
identified as CA certificates and certificates representing an IPSec client are 
identified as IPSec client certificates. 

The XSR uses the SCEP protocol to retrieve certificates for the XSR and any 
CA that may exist in the XSR or peers certificate chain. 

Certificate Revocation Lists (CRLs) are used to ensure that both the XSR and 
any peer certificate are currently valid. CRLs list all certificates that have been 
revoked by CAs before their natural expiration occurs. The XSR must 
validated every IPSec certificate it uses against current CRL lists available 
from CAs in the IPSec client certificates chain. 

The XSR does not allow optional CRL checking mode other systems may 
allow. CRLs are collected automatically by the XSR using information 
available in the IPSec and CA certificates it has already collected. 

Two methods are available to perform this collection: 

□ HTTP Get issues an HTTP-based request to collect the certificate. 

□ LDAP issues URL requests to collect CRLs. 

Most CAs can be configured to use either or both of these CRL retrieval 
mechanisms. The XSR automatically adjusts to use one method or the other 
based on information stored in the certificates. 

CA Hierarchies 

In large organizations, it may be advantageous to delegate the responsibility 
for issuing certificates to several different CAs. For example, the number of 
certificates required may be too large for a single CA to maintain; different 
organizational units may have different policy requirements; or it may be 
important for a CA to be physically located in the same geographic area as the 
people to whom it is issuing certificates. 
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It is also possible to delegate certificate-issuing responsibilities to subordinate 
CAs. The X.509 standard includes a model for setting up a hierarchy of CAs. 
As shown in Figure 40, the root CA is at the top of the hierarchy. The root 
CA's certificate is a self-signed certificate: that is, the certificate is digitally 
signed by the same entity - the root CA - that the certificate identifies. 

The CAs that are directly subordinate to the root CA have CA certificates 
signed by the root CA. CAs under the subordinate CAs in the hierarchy have 
their CA certificates signed by the higher-level subordinate CAs. 
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Figure 40 Sample Hierarchy of CAs 



Certificate Chains 

CA hierarchies are reflected in certificate chains. A certificate chain is series of 
certificates issued by successive CAs. Figure 41 shows a certificate chain 
leading from a certificate that identifies some entity through two subordinate 
CA certificates to the CA certificate for the root CA (based on the CA 
hierarchy shown in Figure 40). 
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Figure 41 Certificate Chain Example 



A certificate chain traces a path of certificates from a branch in the hierarchy 
to the root of the hierarchy. In a certificate chain, the following occurs: 

□ Each certificate is followed by the certificate of its issuer. 

□ Each certificate contains the name of that certificate's issuer, which is 
the same as the subject name of the next certificate in the chain. 

In Figure 41, the Admin CA certificate contains the name of the CA 
(that is, US CA), that issued that certificate. USA CA's name is also 
the subject name of the next certificate in the chain. 

□ Each certificate is signed with the private key of its issuer. The 
signature can be verified with the public key in the issuer's certificate, 
which is the next certificate in the chain. 

In Figure 41, the public key in the certificate for the U.S. CA can verify 
the U.S. CA's digital signature on the certificate for the Admin CA. 
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The XSR will automatically verify the certificate chain structure associated 
with any IPSec client certificate once it manually collects certificates for all 
CAs in the chain. This includes the chain that exists for the certificate enrolled 
by the XSR and chains for any IPSec peer who will establish tunnels with the 
router. They must be collected manually but they are automatically chained 
together using information in the CA Client certificates. You do not have to 
manually create these chains. 

CA certificates are collected using the SCEP authentication mechanism and 
stored in a local certificate database. The XSR's IPSec client certificate is 
enrolled in a CA using the SCEP enroll command, and is stored in the local 
certificate database. Certificates for peer IPSec clients are passed to the XSR 
by IKE and are used to authenticate the peer then discarded. 

RA Mode 

Some CA implementations distribute the CA's operation/ authentication of 
clients to RA agents. The Microsoft CA implements its CA in such a fashion. 
The XSR will automatically adjust to the CA's mode of operation: you need 
not specify whether your CA uses RA mode or not. If your CA uses RA mode 
you will notice more then one certificate for the CA after you authenticate 
against the CA. 

Pending Mode 

Once you've authenticated against a CA that will be the parent CA in your 
XSR certificate chain, you then enroll the XSR's IPSec client certificate against 
the CA using the SCEP enroll command. Depending on how your CA 
administrator has configured the CA, you may or may not immediately 
receive your IPSec client certificate when you first enroll. If the CA has been 
configured to use pending mode, the CA administrator must manually issue 
or deny your request. The CA administrator may take certain steps to verify 
that the enrollment request is valid such as calling the system administrator. If 
so, this process may take a number of hours or days. 

When pending mode is configured, the XSR will log that the operation in 
pending, and will automatically poll for the certificate three times over five- 
minute intervals. The number of polls and interval between polls is adjustable 
using CLI commands under Crypto Identity Configuration mode. This 
assumes that the CA administrator will issue or deny the XSR enrollment 
request in a 15-minute window. 
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Once retries are exhausted, the enrollment becomes invalid and you must 
enroll again - each poll request and its result are logged in detail by the XSR. 
Ask your CA administrator what these values should be set to. 

Enroll Password 

Another way to verify where the IPSec client enroll derives from is to have the 
CA administrator issue a specific password for your enrollment. This can either 
be done manually or through a Web page at the CA. If you are required to 
provide a specific password for the enrollment you must use that password or 
your enrollment will fail. If you are allowed to create your own password, be sure 
to remember it because it is required if you ever wish to revoke a certificate. 

CRL Retrieval 

As mentioned earlier, a CRL must be retrieved for any IPSec client certificate 
the XSR uses for authentication. This is done automatically by the 
XSR whenever a new certificate is encountered and on a maintenance cycle 
that by default occurs every 60 minutes. Depending on your CA's 
configuration, you may want to adjust how frequently your maintenance task 
runs. Ask your CA administrator what this value should be set to. 

Renewing and Revoking Certificates 

A certificate has a specific lifetime and will eventually expire. Additionally, 
certificates can be revoked at the CA before their expiration time is reached. 
When a certificate expires, the XSR must re-authenticate for CA certificates, or 
re-enroll for its IPSec client certificate: this is not an automatic process. 

Only the CA administrator can revoke a certificate - the password used to 
create the certificate during enrollment is required to revoke it. Revoked 
certificates will appear on the next CRL. Discuss these periods and strategies 
with your CA administrator. 

DF Bit Functionality 

The XSR's DF bit override feature with IPSec tunnels configures the setting of 
the DF bit when encapsulating tunnel mode IPSec traffic. If the DF bit is set to 
clear, the XSR can fragment packets regardless of the original DF bit setting. 
The DF (Don't Fragment) bit within the IP header determines whether a 
router is allowed to fragment a packet. 
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This feature specifies whether the router can clear, set, or copy the DF bit in the 
encapsulating header. It is available only for IPSec tunnel mode - transport 
mode is not affected because it does not have an encapsulating IP header. 
Typical enterprise configurations of DF bit include hosts which perform the 
following functions: 

□ Use firewalls to block Internet Control Message Protocol (ICMP) errors 
from outside the firewall, preventing hosts from learning about the 
Maximum Transmission Unit (MTU) size outside the firewall 

□ Set the DF bit in packets they send 

□ Use IP Security (IPSec) to encapsulate packets, reducing the available 
MTU size 

If your topology includes hosts which screen knowledge of the available 
MTU size you can set the XSR to clear the DF bit and fragment the packet. See 
"XSR with VPN - Central Gateway" on page 277 for a sample configuration. 

i NOTE 

DF bit can be configured globally or per interface. If both levels are 
configured, Interface will override Global mode. Also, it is supported on 
any interface on which VPN can be configured. 



VPN Applications 

The XSR supports the following applications: 

□ Site-to-Site (Peer-to-Peer) - XSRs establish connections between each 
other, ANG-1102/ 1105s, 7000s, or third-node devices via the Internet 
based on certificates and pre-shared keys. While this is the simplest 
tunnel to set up, it does not provide as rich a functionality set as a Site- 
to-Central Site tunnel. 

□ Site-to-Central-Site - XSRs, performing as tunnel servers with Client or 
Network Extension Mode enabled, establish connections between each 
other, ANG-1102/1105s or 7000s based on pre-shared key and 
certificates. This type of tunnel offers several advantages over a Site-to- 
Site tunnel including: 

- RIP or OSPF routing is supported 
Tunnel heartbeats are supported 
Tunnel failover is consistently supported 
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- Tunnels are more easily scalable in multiple router topologies 

- Network managment is more robust 

□ Remote Access - XSR functions as a tunnel server, establishing dial-up 
connections with clients over the Internet via local ISPs. 

The XSR supports multiple combinations of the above applications and 
includes auxiliary functionality such as: 

- RADIUS authentication 

- PKI authentication 

- NAT traversal 

- IP address management 

- Dynamic routing over VPN (remote access only) 

- OSPF over VPN 

- DF Bit override on IPSec tunnels 

Site-to-Site Networks 

Site-to-site tunnels operate as point-to-point connections and are used to 
leverage a relatively inexpensive connection to the Internet, replacing costly 
leased lines. They are useful when connecting geographically dispersed 
network segments where each segment contains servers and hosts. VPN 
tunnels play the role of point-to-point links and are transparent from a 
routing perspective. 

Figure 42 shows a link between two XSR sites, but this architecture can be 
extended to link many sites by creating a mesh topology. 

Because routing data is exchanged over the established tunnels each site is 
able to reach any other site. While it is extremely flexible for mesh networks, 
site-to-site is also useful within a hub-and-spoke topology. 
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Figure 42 VPN Site-to-Site Topology 



It is important to note that routers /VPN gateways which terminate tunnels 
cannot reside behind a NAT device because external addresses must be valid, 
routable addresses. This factors into a site-to-site tunnel scenario where both 
XSRs play an equivalent role and any VPN gateway can initiate a tunnel. 

VPN gateways terminating a tunnel cannot run routing protocols, therefore 
must solely rely on static routes. Only packets destined for networks behind 
the peer will be encrypted and shipped via a tunnel. Other traffic will either 
be dropped or forwarded to the Internet depending on your security policy. 

Authentication for IPSec tunnels is performed using pre-shared keys or 
certificates. Authentication using pre-shared keys is acceptable in this 
application because the number of connected peers is relatively small. 

Since the XSR uses IETF standards to build tunnels, it can link with other 
vendor devices. Multi-protocol traffic can be exchanged over the tunnels, but 
must first be encapsulated in the GRE protocol then encrypted using IPSec. 
Refer to "Configuring a Simple VPN Site-to-Site Application " on page 271 
and "Configuration Examples" on page 277 for detailed Site-to-Site setups. 
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Site-to-Central-Site Networks 

In a Site-to-Central-Site application, connecting nodes are not equivalent. One 
node initiates a connection and the other accepts the connection. In practice, the 
node initiating the connection represents the smaller entity and connects to the 
bigger corporate network. Since the connection is always initiated by one site, 
the initiating node can reside behind an ISP-operated NAT device. But, the 
presence of NAT requires the IPSec modification known as NAT traversal. 

Depending on the type of IP address management configured on the 
connecting site of this application, site-to-central-site networks can be built 
two ways, as shown in Figure 43. 
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Figure 43 Site-to-Central-Site Topology 



XSR User's Guide 



243 



VPN Applications 



Chapter 11 

Configuring the Virtual Private Network 



Client Mode 

In the Client scenario, a private LAN residing behind the XSR is hidden from 
the corporate network. When the XSR connects to the Central site tunnel 
server, the tunnel server assigns the router an IP address which can be chosen 
from an internal pool kept by the tunnel server or from a DHCP server 
located on the corporate network. Hosts residing on the private LAN obtain 
IP addresses from a DHCP server running within the XSR. 

Each session between a host on the private LAN and a server on the corporate 
network is NAT-ed by a NAT device within the XSR. From the corporate 
perspective the entire private LAN is represented as a single IP address. This 
application is limited in that hosts on the private LAN are not visible from the 
corporate network, so any session must be initiated from the hosts on the 
private LAN. Another limitation is that the XSR's internal NAT operates only 
on Layer-4 protocols such as TCP and UDP NAT also employs a set of 
modules - Application Level Gateway (ALG) - processing non-UDP/TCP 
protocols such as ICMP and H323. 

Routing updates are unidirectional - the Central site advertises segments 
reachable in the corporate network, but the XSR does not advertise the 
private LAN. After receiving a routing update, the XSR can leverage a 
connection to the Internet for a VPN connection and access public services 
located on the Internet such as Web servers. 

A secure tunnel to the Central site tunnel server is established by means of 
IETF ISAKMP Aggressive Mode with pre-shared keys or Main Mode using 
certificates. The assignment of IP addresses requires the support of Config 
Mode on the tunnel server and the XSR. Since Config Mode is not 
standardized, using it may affect interoperability with third-party devices. 

The Client application also supports the XSR's EZ-IPSec technique and off- 
loading administrator. Most configuration is performed on the Central site and 
specified values are pushed to the connecting device during tunnel creation. 

Network Extension Mode (NEM) 

In the Network Extension scenario, as illustrated in Figure 43, the branch 
LAN is visible from the corporate segment since addressing used on that 
LAN augments addressing used on the corporation network. Hosts located 
on the branch LAN obtain IP addresses from the main DHCP server located 
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on the corporate network. In this application the XSR must support the DHCP 
Relay protocol (RFC-3046) to extend hosts' DHCP requests for IP addresses. 
An obvious limitation of this configuration is that hosts cannot obtain IP 
addresses before a tunnel to the corporate network is created. A secure tunnel 
to the tunnel server is established by means of IETF ISAKMP Aggressive 
Mode transaction with pre-shared keys or Main Mode using certificates. 

Remote Access Networks 

In a Remote Access application, as shown in Figure 44, a client connects to the 
corporate network in the same way as a dial-in user does. First, the client 
connects to an ISP and is assigned an external IP address, which is used to 
route packets over the Internet. 

Then, the remote client initiates a tunnel to the XSR and is assigned an 
internal IP address belonging to the corporate network. An IP address given 
to the connecting client can be taken from an internally managed pool created 
by a DHCP or RADIUS server located on the corporate network. After 
connecting, the remote client operates as if directly connected to the corporate 
LAN. 




Corporate network 



Routing 
updates 



VPN tunnel 



VPN Gateway 
IP address assigned 
by VPN Gateway 



External address 
assigned by ISP 



Server RADIUS server DHCP server 



Figure 44 VPN Remote Access Topology 



Many protocols provide remote access functionality. Windows 95/98 
supports remote access using PPTP with MPPE. Windows 2000 supports 
L2TP over IPSec and proprietary solutions such as the Indus River Tunneling 
Protocol IRTP (Enter asys Networks) are also available. 
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Depending on the protocol, the remote access scenario may require user 
authentication as well as machine authentication. A user database may be 
located on the XSR itself or a RADIUS server. After a tunnel has been built, 
the XSR may advertise routing information about the corporate network to 
the client which can use this information to share a connection to the Internet 
between secure tunnel and reach public services on the Internet. 

XSR performs as a tunnel server, its role to authenticate connecting clients 
and assign them IP addresses. Authentication can be performed in several 
ways depending on the protocol used. 

For PPTP, authentication is achieved by means of PPP-based authentication 
methods such as MS-CHAP, EAP, PAP, and CHAP. It should be noted that 
some of these methods are not secure because password and user IDs traverse 
the Internet in clear-text. In the case of PPTP, the machine is not authenticated. 

With L2TP over IPSec, before an L2TP connection can be established between 
a client and the XSR, an IPSec connection must be created. The IPSec 
connection is authenticated based on certificates installed on the connecting 
device and in the XSR or pre-shared keys. 

User authentication is PPP-based, but since the L2TP session is protected by 
IPSec, any form of PPP authentication is secure. 

Using OSPF Over a VPN Network 

OSPF functions on the XSR to dynamically discover networks and adjust the 
routing table when network connections fail. The VPN protocol provides 
secure packet transport over the public network by the use of cryptographic 
policies attached to XSR interfaces which secure selected flows of traffic. 

When OSPF and VPN protocols are both employed over a network, 
contradictions may arise. For example, OSPF may advertise that a particular 
network segment is reachable but VPN policies may prohibit traffic destined 
for that segment. 

To avoid this problem, you must use care when configuring both protocols. 
The following sections describe different VPN scenarios and how OSPF is 
employed within them. 
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OSPF Commands 

The same OSPF commands available for configuration in 
FastEthernet/ GigabitEthernet or Serial Interface mode are available in 
Interface VPN mode. They are: 



□ 




ospf 


authentication -key 


□ 


ip 


ospf 


cost 


□ 


ip 


ospf 


dead- interval 


□ 


ip 


ospf 


hello- interval 


□ 


ip 


ospf 


message -digest -key- 


□ 


ip 


ospf 


priority 


□ 


ip 


ospf 


retransmit- interval 


□ 


ip 


ospf 


transmit -delay 



Additionally, show ip ospf interface vpn is available in EXEC mode. 

Configuring OSPF Over Site-to-Site in Client Mode 

When the XSR is configured in a Client Mode, Site-to-Site application, it 
creates an asymmetric connection with one side acting as the server and other 
the client. The client initiates the tunnel upon node startup, requesting an IP 
address from the server. 

From the client's point of view, the tunnel is a point-to-point connection; the 
VPN (virtual) interface associated with the tunnel must be a point-to-point 
connection. The server terminates connections from more than one client. 
Each connected client is issued an IP address. 

From the server's point of view, connected tunnels form point-to-multipoint 
links. Additionally, the server does not see a segment behind the client, 
because in Client Mode NAT is employed inside the tunnel and all traffic 
originated from trusted segment is NAT-ed to use an IP address assigned by 
the server, as shown in Figure 45. 
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Private segment invisible from server the server's VPN interface. 



Figure 45 Site-to-Site Client Mode Topology 

In this scenario, you may use OSPF to advertise the corporate network's 
reachability via an established tunnel. OSPF can also monitor the health of a 
VPN link. 

Advertising these networks becomes extremely valuable when the client 
connects to more than one server. In that case, the client will maintain two 
VPN interfaces, expressed on the XSR as VPN 1 and VPN 2. Routes learned 
by OSPF will instruct the IP routing engine which IP addresses are reachable 
via the VPN 1 interface and which are reachable via the VPN 2 interface. 
Based on the example shown in Figure 45, the following OSPF settings should 
be applied to the interfaces. 
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Server 

□ FastEthernet 1 interface: This is the trusted side of the network on the 
XSR. It may consist of more than one IP segment. A network attached 
to FastEthernet 1 will be advertised in an OSPF area. 

□ VPN 1 interface: OSPF is required here to establish adjacency with 
connecting clients. From the point of view of OSPF, a set of connected 
clients is treated as a point-to-multipoint network. Before exchanging 
OSPF packets, the server must separately establish adjacency with each 
connected client. If the server cannot establish OSPF adjacency with 
them, it will not send OSPF updates to clients. 

□ FastEthernet 2 interface: OSPF must be disabled here because this is the 
default, external connection to the Internet. The server should not 
receive updates from the Internet nor pass along information about 
private segments to the Internet. 

Client 

□ VPN 1 interface: OSPF must be enabled on this interface to receive 
updates from the server. 

□ FastEthernet 2 interface: OSPF should be disabled here for the same 
reason it is disabled on the server. 

□ FastEthernet 1 interface: This is private, non-routable segment, usually 
192.168.1.0/24. If OSPF is enabled on this interface it will be advertised 
to the server. The server's IP routing table will learn a route to this 
segment via the VPN interface connected to the client. But it is 
unreachable because NAT is enabled. Be aware that if two clients 
advertise the same private segment, e.g., 192.168.1.0/24, the server will 
learn two routes, which seem to be the same destination, but in fact are 
not. OSPF must then be disabled on Fl. 

If other clients connecting to the VPN 1 interface on the server do not have 
OSPF coverage (i.e., Windows remote access clients), OSPF ignores them and 
continues exchanging information with those clients which support OSPF. 

On the client, a tunnel associated with interface VPN 1 is created by means of 
the XSR's EZ-IPsec functionality. EZ-IPsec automatically inserts SPDs on 
FastEthernet interface 2 which specify that only traffic from and to the IP 
address assigned by the server should be encrypted. There is no conflict 
between SPDs and OSPF routing on this connection. 
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The commands to configure this scenario are illustrated on page 277. 

Configuring OSPF Over Site-to-Site in Network Extension Mode 

Compared to Site-to-Site Client Mode configuration, Network Extension 
Mode is more flexible at the cost of a more sophisticated configuration. As 
shown in Figure 46, NAT is not used on the VPN interface at the client site as 
it is in the Client Mode application. The trusted network behind the client is a 
fully routable segment and may be reached from the server. 
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Figure 46 Site-to-Site Network Mode Topology 



In this scenario, the VPN interface on the server may terminate a mix of 
connections - some of which may be Client-type connections and others may 
be Network Extension connections. 

The following OSPF settings should be applied in this scenario: 
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Server 

Apply the same settings as in the site-to-site scenario using Client Mode. 
OSPF is enabled on Fl and VPN 1 interfaces and is disabled on F2. 

Client 

□ Similar to the Client Mode model, OSPF is enabled on VPN 1 and 
disabled on FastEthernet 2. 

□ Additionally, OSPF is enabled on FastEthernet 1 because the route to 
network FastEthernet 1 should be learned at the central site's network. 

The tunnel associated with interface VPN 1 on the client is created by EZ- 
IPsec which automatically creates and attaches two sets of SPDs to interface 
FastEthernet 2. The first set specifies that traffic to and from the IP address 
assigned to the client by the server should be encrypted. The second set's SPD 
specifies that traffic originating from and destined for the segment attached to 
FastEthernet 1 should be encrypted. 

Network extension mode lets you add more segments attached to interface 
Fl. If those segments are advertised using OSPF, routes to those segments will 
be known at the central site network. But, any traffic destined for those 
segments will be dropped because security policy described by crypto maps 
prohibits such traffic. 

This situation may be addressed by extending crypto maps attached to both 
the client and the server. An example of such a network extension is 
illustrated in "XSR with VPN - Central Gateway" on page 277, where an 
additional segment not directly attached to the client's trusted segment has IP 
address 60.60.60.0/24. 

^ / note 

When OSPF is configured over a NEM tunnel to a central site XSR, 
remote access Microsoft clients at the branch XSR must check the "Use 
default gateway on remote network" box in the Advanced TCP/IP 
Settings dialog in order to reach all subnets. This setting is located in the 
Network Connections dialog by clicking Start/ Connect To/Show all 
connections /Virtual Private Network: <Your Remote Access Dialog> 
/Properties /Networking tab/Internet Protocol [TCP/IP) box: 
Properties/ Advanced. 
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Configuring OSPF with Fail Over 

In this scenario, the client initiates two tunnels to two servers which are 
connected on their trusted sites. With alternative paths to the trusted network 
behind the server (via the client's two tunnels), OSPF learns two paths of 
identical costs but uses the first learned path. 

Should the tunnel serving that path become non-functional, OSPF 
recalculates the routes and uses the alternate path. The interval between link 
failure and the switch to the new route depends on the following OSPF 
parameters set on the VPN interfaces: 

□ hello-interval - This specifies how often hello packets are sent to the 
neighbor. 

□ dead-interval - This sets the peak interval which may elapse without 
receiving hello packet from the neighbor before the link is declared 
non-operational. 

Setting those parameters low will generate more traffic on the link but 
guarantees faster detection of link failure. As shown in page 253, OSPF is 
enabled on the following interfaces: 

Server 1 

Interfaces FastEthernet 1 and VPN 1 
Server 2 

Interfaces FastEthernet 1 and VPN 1 
Client 

Interfaces FastEthernet 1, VPN 1 and VPN 2. 
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Figure 47 OSPF Used with Failover 

To test this configuration, attach an FTP server to the corporate network and 
an FTP client to the client's network with the hello-interval set to 2 seconds 
and dead-interval to 6 seconds on the VPN interfaces. Then initiates an FTP 
transfer from the server to the client. During the transfer, intentionally break 
the tunnel used for data transfer. After 6 seconds, OSPF will declare the link 
non-operational and resume the FTP transfer. 

Limitations 

IPSec may also be used without configuring the VPN interface by applying 
crypto maps to physical interfaces. In this application, IPSec is treated as a side 
effect of data transmission through the interface. Since no virtual interface 
(VPN1, e.g.) is applied to the IPSec connection, a routing protocol like OSPF 
cannot be configured. 
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As mentioned earlier, OSPF may advertise a network's reachability but IPSec 
policies may deny access to that network. To avoid that situation, you may 
extend crypto maps attached to interfaces, but this requires prior knowledge 
of networks advertised by OSPF, which renders OSPF's dynamic network 
discovery useless. In this case, OSPF is used only for monitoring the links and 
providing alternate routes in case of link failure. 

XSR VPN Features 

The XSR supports the following VPN features: 

□ Site-to-Site (Peer-to-Peer) application 

IPSec /IKE with pre-shared secrets 

- IPSec/IKE with certificates (PKI) 

- EZ-IPSec with PKI or pre-shared secrets: 

- Network Extension Mode (NEM) 

- Client mode 

□ Remote Access application 

- Clients 

- Windows XP and 2000 (L2TP); NT 4.0, 98, 98 SE, ME, and CE. 
PPTP is available on all Windows clients 

- L2TP/IPSec protocols 

SCEP: Certificate and PKI environment 

- MS-CHAP v2, EAP user authentication: 

- - Username/ Password (local database and RADIUS) 

- - SecurlD (third-node plug-in) 

- - Certificates (embedded/ smart cards) - Microsoft only 

- PPTP protocol 

- - MS-Chap V2, EAP user authentication 

- Local Database and RADIUS 

- - SecurlD (third-node plug-in) 

- - Certificates (embedded/ smart cards) - Microsoft only 

□ Encryption 

- Advanced Encryption Standard (AES), Triple Data Encryption 
Standard (3DES), Data Encryption Standard (DES) 

- 3DES acceleration available 
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□ Data integrity 

- MD5 and SHA-1 algorithms 

□ Internet Protocol Security (IPSec) 

Encapsulating Security Payload (ESP), Authentication Header 
(AH) and IPComp 

- Tunnel and Transport mode 

- Diffie-Hellman Groups 1, 2 and 5 

- Mode Config for IP address assignment 

- NAT Traversal via UDP encapsulation 

□ Public Key Infrastructure (PKI) 

- Microsoft Certificate Authority (CA) support 

- Simple Certificate Enrollment Protocol (SCEP) 

- Microsoft Simple Certificate Enrollment Protocol (MSCEP) 

- Chained CA support 

- CRL checking (Hypertext Transfer Protocol [HTTP] and 
Lightweight Directory Access Protocol [LDAP]) 

□ Network Address Translation (NAT) protocol 

- Static NAT 

- NAPT 

□ Dynamic Host Configuration Protocol (DHCP) 

- DHCP Server 

□ OSPF over VPN 

□ DF Bit override on IPSec tunnels 

VPN Configuration Overview 

IPSec configuration entails the following basic steps. First, decide what type 
of VPN you want to configure from the following choices: 

□ Site-to-Site (Peer-to-Peer) using either pre-shared key or digital 
certificate (PKI) authentication 

□ EZ-IPSec using Client or Network Extension mode 

□ Remote Access using either L2TP/ IPSec or PPTP 

Consider that in Site-to-Site applications, the XSR can act as a gateway, or 
terminator, of the tunnel and also as the client, or initiator, of the tunnel. In 
Remote Access applications, the router can only terminate connections. 
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Next, perform the following: 

□ Generate a master key once on the XSR 

□ Define a Security Policy Database (SPD) by configuring crypto ACLs 
which specify the type of traffic to be secured 

□ Specify policies - IKE and IPSec transform-sets which spell out 
authentication, encryption, data integrity, policy lifetime, and other 
parameters to use when negotiating IPSec Security Associations (SAs) with 
IPSec peers. 

□ Create crypto maps to apply SPD, transform-sets and ACLs to an interface 

□ Configure authentication via AAA and/ or PKI 

□ Set up optional auxiliary functions including RADIUS, IP address 
assignment, and NAT. 

□ Optionally configure a VPN interface 

Master Key Generation 

The XSR stores sensitive data such as user names, passwords, and certificates. 
Because retaining this data in the clear would pose a security risk, the XSR 
uses a master encryption key to encode locally stored information. The router 
is not supplied with master encryption key at the factory - you must 
manually generate it before starting any VPN configuration. To do so: 

□ Enter crypto key master generate in Global configuration mode. 



The master encryption key is stored in hardware, not Flash, and you 
cannot read the key - only overwrite the old key by writing a new one. 
To ensure router security, it is critical not to compromise the key. There 
are situations where you may want to keep the key, for example, to save 
the user database off-line in order to later download it to the XSR. In 
order to encrypt the user database, you need the same master key, 
indicating the key designation with the master key specify 
command. 

Be aware that if the XSR is inoperable and you press the Default 
button, the master key is erased and you must generate a new one. 




WARNING 
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ACL Configuration Rules 

Consider a few general rules when configuring ACLs on the XSR: 

□ Typically, two ACL sets are written, one set to filter IPSec/IKE traffic 
(defined in crypto maps), and a simple set to filter non-IPSec traffic. 

□ When crypto maps and ACLs are configured on the same interface, the 
XSR gives precedence to the crypto map, which is always consulted 
before the ACL for both inbound and outbound traffic. If IPSec 
encrypts or decrypts packets by virtue of a crypto map configuration, 
then the ACL is ignored. 

□ ACLs entered independently are uni-directional but are rendered bi- 
directional when later associated with a crypto map through the match 
address <acl #> command. 

□ A total of 500 ACL entries are permitted by the XSR with 64 MBytes of 
RAM installed (99 ACL limit for IKE/IPSec). 

Configuring ACLs 

Three simple ACL examples illustrating various CLI options are detailed 
below. Other crypto map ACLs, defined in greater detail, are configured later 
in this chapter. 

The first ACL example is fairly restrictive. It configures ACL 101 to permit 
IKE (UDP port 500), GRE, and TCP traffic on any internal host to pass to host 
141.15.6.17 (denying all other traffic) and ACL 102 to permit the same type of 
traffic on host 141.15.6.17 to connect to any address (denying all other traffic). 

The commands on FastEthernet port 2 set ACL 101 to filter inbound traffic, 
and ACL 102 to filter outbound traffic. Some commands are abbreviated. 

XSR (conf ig) #acc 101 permit udp any host 192.168.2.17 eq 500 
XSR (conf ig) #access-list 101 permit gre any host 192.168.2.17 
XSR (conf ig) #acc 101 permit tcp any host 192.168.2.17 estab 
XSR (conf ig) #access- list 101 deny ip any any 

XSR (conf ig) #acc 102 permit udp host 192.168.2.17 any eq 500 
XSR (conf ig) #access-list 102 permit gre host 192.168.2.17 any 
XSR (conf ig) #acc 102 permit tcp host 192.168.2.17 any eq 80 
XSR (conf ig) #access-list 102 permit ip host 192.168.2.17 any 
XSR (conf ig) #access-list 102 deny ip any any 
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XSR(config) #interface FastEthernet2 

XSR (conf ig-if <F2>) #no shutdown 

XSR (conf ig-if <F2>) #ip access-group 101 in 

XSR (conf ig-if <F2>) #ip access-group 102 out 

XSR(config-if<F2>) #ip address 141.154.196.87 255.255.255.192 

If an XSR is configured as a VPN gateway, the external interface (FastEthernet 
2, e.g.), can be made more restrictive by only allowing VPN protocols to pass 
through and barring all other traffic: 

XSR (conf ig) #access-list 100 permit esp any host 192.168.57.7 
XSR (conf ig) #access-list 100 permit ah any host 192.168.57.7 
XSR (conf ig) #access-list 100 permit udp any eq 500 host 
192.168.57.7 eq 500 

XSR (conf ig) #access-list 101 permit esp host 192.168.57.7 any 
XSR (conf ig) #access-list 101 permit ah host 192.168.57.7 any 
XSR (conf ig) #access-list 101 permit udp host 192.168.57.7 eq 500 
any eq 500 

XSR (conf ig-if <F2>) #interface FastEthernet2 
XSR (conf ig-if <F2>) #no shutdown 
XSR (conf ig-if <F2>) #ip access-group 100 in 
XSR (conf ig-if <F2>) #ip access-group 101 out 

The following ACL example is fairly open, configuring the XSR as a VPN 
concentrator but allowing internal users access to the Internet. ACLs 101 and 
102 are applied to the external interface - FastEthernet 2. 

ACLs must be applied to the external interface of the XSR prior to the creation 
of a VPN configuration. These ACLs would only be applied to an XSR 
configured as a VPN concentrator that would also be used for Internet access. 

XSR (conf ig) #access-list 101 permit udp any any eq 500 
XSR (conf ig) #access-list 101 permit gre any any 
XSR (conf ig) #access-list 101 permit tcp any any established 
XSR (conf ig) #access-list 101 permit tcp any any eq 1723 
XSR (conf ig) #access-list 101 permit tcp any any eq 1701 
XSR (conf ig) #access-list 101 permit tcp any any eq 389 
XSR (conf ig) #acc 101 pe ip host <public interface address> any 
XSR (conf ig) #access- list 101 deny ip any any 

XSR (conf ig) #access-list 102 permit udp any any eq 500 
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XSR (conf ig) #access-list 102 permit gre any any 

XSR (conf ig) #access-list 102 permit tcp any any 

XSR (conf ig) ttaccess- list 102 permit tcp any any 

XSR (conf ig) #access-list 102 permit tcp any any 

XSR (conf ig) #access- list 102 permit tcp any any 

XSR (conf ig) #access-list 102 deny ip any any 

XSR (conf ig) #interf ace fastethernet 2 
XSR (conf ig-if<F2>) #ip access-group 101 in 
XSR (conf ig-<F2>) #ip access-group 102 out 

Selecting Policies: IKE/IPSec Transform-Sets 

IKE transform-sets are configured by the crypto isakmp proposal 
command with the following parameters available: 

- Pre-shared key or RSA signatures public key authentication 
3DES, AES, or DES encryption 

- Group 1, 2, and 5 Diffie-Hellman 768-, 1024-, and 1536-bit 
MD-5 or SHA-1 hash algorithms 

SA lifetimes 

More than one IKE proposal can be specified on each node. When IKE 
negotiation begins, it seeks a common proposal on both peers setting identical 
parameters. Additional parameters related to IKE are configured using the 
crypto isakmp peer command. Specified parameters are effective when a 
peer address/ subnet matches the IP address of the peer. The wildcard 0.0.0.0 
0.0.0.0 may be used to match any peer. Other configurable IKE values are: 

IKE peer address/subnet 
IKE proposal list 

Mode-config options client or server 

Main or aggressive IKE exchange mode options 

NAT automatic, enabled or disabled options 

Transform-sets used for IPSec are set with the crypto ipsec transform- set 
command. You can choose AH, ESP, or IP compression values as follows: 

- MD5-HMAC or SHA-HMAC hashing algorithms 

- COMP-LZS IP compression with the LZS compression algorithm 
3DES, AES or DES encryption 



eq 80 
eq 1723 
eq 1701 
eq 389 
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Security Policy Considerations 

You should be aware of these considerations when configuring security policy: 

□ DES is a weaker form of encryption than 3DES and provides a lower 
level of security than the newer algorithm. We recommend 3DES. 

□ Selecting any Perfect Forward Secrecy (PFS) option will make each 
generated key used in data encryption independent of previous keys. If 
the key is compromised, the next key generated by Phase 2 exchange 
cannot be determined by knowing the value of the previous key. This 
comes at the cost of slightly lower performance. 

□ Two IPSec encapsulation modes - tunnel and transport - are supported 
but the default, tunnel mode, is typically used with VPNs because it is 
more inclusive. 

Configuring Policy 

The following example defines simple IKE Phase I, remote peer and IPSec 
transform-sets. Configure the IKE proposal tryl: 

XSR (conf ig) #crypto isakmp proposal tryl 

XSR (conf ig- isakmp) #authentication pre -share 

XSR (conf ig- isakmp) #encryption aes 

XSR (conf ig- isakmp) #hash md5 

XSR (conf ig- isakmp) #group 5 

XSR (conf ig-isakmp) #lifetime 40000 

Configure IKE policy for the remote peer, assuming that two other IKE 
proposals {try! and try 3) have been configured: 

XSR (conf ig) #crypto isakmp peer 192.168.57.33/32 
XSR (conf ig-isakmp-peer) #proposal tryl try2 try3 
XSR (conf ig-isakmp-peer) #conf ig-mode gateway 
XSR (conf ig-isakmp-peer) #nat auto 

Configure the IPSec transform set. You can specify both kilobyte and seconds 
SA lifetime values or just one. Some commands are abbreviated. 

XSR (conf ig) #cry ips tr esp-3des-sha esp-3des esp-sha-hmac 
XSR (cf g-crypto- tran) #set pfs groupl 

XSR (cf g-crypto- tran) #set sec lifetime kilobytes 500000 
XSR (cf g-crypto- tran) #set sec lifetime seconds 3000 
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Creating Crypto Maps 

Crypto maps filter and classify packets as well as define the policy to be applied 
to those packets. Filtering /classifying affects the traffic flow on an interface 
while policy affects the negotiation performed (via IKE) on behalf of that traffic. 

IPSec crypto maps link definitions of the following: 

□ Which traffic should be protected by ACLs, set with match address. 

□ Which IPSec peers the protected traffic can be forwarded to by entering 
set peer. These are peers with which an SA can be set up. 

□ Which transform-sets are acceptable with protected traffic configured 
by using set trans form- set. 

□ How keys and SAs are used. 

□ Which encapsulation type, tunnel or transport, should be used, 
configured by entering mode. 

□ Which SAs should be sought for each source/ destination host pair, set 
with set security-association level per-host. This command 
creates separate SAs per data stream. When it is off, each data stream 
passes through the same SA. 

Configuring Crypto Maps 

Crypto maps are a collection of rules indexed by their sequence number. For a 
given interface, certain traffic can be forwarded to one IPSec peer with specified 
security applied to it, and other traffic forwarded to the same or a different 
IPSec peer with different IPSec security applied. 

To do so, create two crypto maps, each with the same map-name, but each with a 
different seq-num. Crypto maps sharing a given map-name are searched in order 
or seq-num. Sequence numbers are an anti-replay device used to reject duplicate 
and old packets thus preventing an intruder from copying a conversation to 
work out encryption algorithms. 

The following crypto map highflozv with sequence # 77 is correlated with the 
specified transform-set and ACL 140 by the match command, which also 
renders ACL 140 bi-directional. It is attached to a remote gateway, specifies 
that only one SA be requested for each crypto map ACL permit entry, and 
automatically accepts IPSec tunnel mode (when set peer is configured). 

XSR (conf ig) #access-list 140 permit ip 192.168.57.0 0.0.0.255 

192.168.58.0 0.0.0.255 

XSR (conf ig) #crypto map highflow 77 
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XSR (conf ig-crypto-m) #set transform- set esp-3des-sha 

XSR (conf ig-crypto-m) #match address 40 

XSR (conf ig-crypto-m) #set peer 192.168.45.12 

XSR (conf ig-crypto-m) #no set security-association level per-host 

Authentication, Authorization and Accounting Configuration 

The XSR's AAA implementation configures all authentication, authorization 
and accounting characteristics of users (Remote Access) and peer gateways 
(Site-to-Site). These characteristics include: 

□ Usernames and passwords for authentication 

□ Associated group name for authorization of network services 

□ IP addressing, including: 

- Virtual addresses from a local IP pool 

- DNS (primary and secondary) for remote access clients 

- WINS (primary and secondary) for remote access clients 

□ Compression settings for remote access clients and site-to-site tunnels 

□ Encryption settings for PPTP remote access clients 

□ Configuration for standardized Authentication methods, that is, 
RADIUS. In addition to all the necessary values for communicating 
securely with a RADIUS server, the XSR allows you to specify a backup 
RADIUS server for authentication failover. 

AAA Commands 

The following AAA commands are provided by the XSR: 

□ Configures authentication for users and groups with aaa user and aaa 
group commands as well as the following sub-commands: 

policy specifies SSH, Telnet, Firewall or VPN service for users 
dns- server and wins server configure the IP addresses of 
primary and secondary DNS and WINS servers to distribute to 
remote access users and connecting XSRs. 

ip pool associates a globally defined IP address pool (set with ip 
local pool) with a user group. When a remote access user or 
XSR connects, an IP address is distributed from this pool. Be 
aware that if an AAA user is configured to use a static IP address 
which belongs to a local IP pool, you must exclude that address 
from the local pool. 

- 12tp/pptp compression commands enable compression on 
L2TP and PPTP sessions, respectively, and pptp encrypt mppe 
configures Microsoft Point-to-Point Encryption on a PPTP link. 
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- ip address and group set the IP address and usergroup 
assigned to the remote user. 

□ Configures RADIUS, local or PKI databases with the aaa method 
command as well as the following sub-commands: 

- acct-port sets the UDP port for accounting requests. 

- address specifies the RADIUS server address with either a host 
name or IP address. 

attempts sets the total of consecutive login attempts that must 
transpire before the RADIUS method's backup method is used. 

- auth-port specifies the UDP port for authentication requests. 

- enable initializes the current RADIUS server. 

- group specifies the name of an existing usergroup. 

- hash enable initializes the hash algorithm used for RADIUS. 

- key sets the shared secret used between the XSR and the server 
daemon running on a RADIUS server. 

- qtimeout specifies the queue timeout. 

- retransmit specifies the number of RADIUS server 
retransmissions sent to a server before timing out. 

- timeout sets the interval the XSR waits for the RADIUS server to 
reply before retransmitting. 

- backup creates a name for a backup RADIUS server. 

□ Configures pre-shared keys with aaa user and password 
Configuring AAA 

Pre-shared keys used in a Site-to-Site tunnel are configured using the aaa 
user command with the following conditions applicable: 

□ The Username is the IP address of a peer 

□ The Password is the pre-shared key 

To specify a user and password, enter the following commands: 

XSR (conf ig) #aaa user <xxx.xxx.xxx.xxx> 

XSR (aaa-user) #aaa password ThISisMYShaREDsecRET 

The following sample configuration creates user Jeremiah in the PromisedLand 
usergroup, with DNS, WINS and MPPE encryption, and assigns IP local pool 
remote _users for remote access: 

XSR (conf ig) #aaa group PromisedLand 

XSR (aaa-group) #dns server primary 112.16.1.16 

XSR (aaa-group) #dns server secondary 112.3 0.3 0.2 0 
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XSR (aaa-group) #wins server primary 112.16.1.16 
XSR (aaa-group) #wins server secondary 112.16.1.13 
XSR (aaa-group) #ip pool remoteusers 
XSR (aaa-group) #pptp encrypt mppe 128 

XSR (conf ig) #aaa user Jeremiah 

XSR (aaa-user) #password amen 

XSR (aaa-user) #group PromisedLand 



PKI Configuration Options 

The XSR's PKI implementation offers the following CLI commands to: 
□ Identify and configure attributes of Certificate Authorities using the 



crypto ca identity mode's available commands: 

- enrollment http -proxy specifies SCEP requests to be directed 
though an intermediate proxy server. 

- enrollment url - URL provided to access the CA (consult 
your CA administrator for this address). Any DNS names must 



acme.com but 192.168.1.1). 

- enrollment retry count sets the number of retries for pended 
enrollment requests. 

enrollment retry in period sets the interval between retries 
for pended enrollment requests. 

- crl frequency sets the interval between runs of the CRL 
maintenance task to update CRLs. 

□ Collect a CA certificate from a Certificate Authority by entering crypto 
ca authenticate. Note that you must verify the fingerprint of the CA 
against provided information as part of this operation to assure that the 
CA you access is the CA you expect. 

□ Enroll an IPSec client certificate for your XSR against an authenticated 
CA by entering crypto ca enroll. 

□ Immediately update CRL lists by entering crypto ca crl request. 

□ Display various aspects of the crypto configuration using the following 
show commands: 

- show crypto ca identity displays all configured C A 
identities. 

- show crypto ca certificates displays all collected certificates 
(CA Identities and IPSec client certificates). 

- show crypto ca crls displays a list of applicable CRLs. 
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□ Remove individual certificates using the following commands: 

crypto ca certificate chain 
- no certificate - The serial number can be found in the show 
crypto ca certificates command. 

□ Remove CA identities and all associated CA and IPSec client 
certificates by entering no crypto ca identity <ca name>. 

Configuring PKI 

The main steps to configure PKI are as follows: 

□ Obtain the CA name and URL 

□ Identify the CA, retrieve and authenticate the certificate 

□ Verify the root certificate was received 

□ Configure CA retrieval attributes and update CRLs 

□ Specify a host(s) for the CRL mechanism 

□ Enroll in an end-entity certificate 

□ Verify the end-entity certificate is valid 

□ Optional: change the enrollment retry period and count 

For step-by-step instructions, refer to the following PKI Certificate example. 



NOTE 



If you have multiple CAs in a chained environment, you need only 
identify each CA and obtain each CA certificate within the chain using 
the crypto ca identity and crypto ca authenticate commands, 
respectively, as illustrated in Step 2 on page 266. 



PKI Certificate Enrollment Example 

This PKI example illustrates authenticating to and enrolling with a Certificate 
Authority (C A) for an end-entity certificate for the IPSec gateway. Local IPSec 
uses end-entity certificates to establish SAs for IPSec connectivity. You must 
authenticate against all CAs which may have provided certificates to any of 
the remote systems that may be building IPSec links to the local system. 
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1 Begin by asking your CA administrator for your CA name and URL. 

The CA's URL defines its IP address, path and default port (80). You can 
resolve the CA server address manually by pinging its IP address. 

2 Be sure that the XSR time setting is correct according to the UTC time 
zone so that it is synchronized with the CAs time. For example: 

XSR) #clock timezone -5 0 

3 Specify the enrollment URL, authenticate the CA and retrieve the root 
certificate. Check your CA Website to ensure that the printed fingerprint 
matches the CAs fingerprint, which is retrieved from the CA itself, to 
verify the CA is not a fake. If bona fide, accept the certificate, if not, check 
to be sure the certificate is deleted and not stored in the CA database. In 
certain situations you may need to specify a particular CA identity name. 
Consult your administrator for more information. 

XSR (conf ig) #crypto ca identity PKItestcal 
XSR (conf ig-ca- identity) #enrollment url 
http: //192 .168.1 . 33/certsrv/mscep/mscep . dll/ 
XSR (conf ig-ca -identity) #exit 

XSR (conf ig) #crypto ca authenticate PKItestcal 

Certificate has the following attributes: 
Fingerprint: D423E129 81904CE0 1E6D0FE0 A123A302 
Do you accept this certificate? [yes/no] y 

4 Display your CA certificates to verify all root and associated certificates 
are present. In the RA Mode example below, PKItestcal is the root CA of 
three certificates. Non-RA Mode CAs return one certificate only. 

XSR (conf ig) #show crypto ca certificates 

CA Certificate - PKItestcal 
State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 6083 6846550303873313 94927502 614112809 

Issuer: MAILTOsfoo@foo.com, C=US, ST=MA, L=Andover, 

0=VPN Engin, 0U=Eng, CN=PKI Test Certificate Authority 
Valid From: 2002 Jun 4th, 12:40:46 GMT 

Valid To: 2004 Jun 4th, 12:48:15 GMT 

Subject: MAILT0=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=VPN Eng, OU=Eng, CN=PKI Test Certificate Authority 
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Fingerprint: D423E129 81904CE0 1E6D0FE0 A123A302 

Certificate Size: 1157 bytes 

RA KeyEncipher Certificate - PKItestcal-rae 
State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 458128935273366930063530 

Issuer: MAILTO=f oo@f oo . com, C=US, ST=MA, L=Andover / 

0=VPN Eng, OU=Eng, CN=PKI Test Certificate Authority 
Valid From: 2002 Jul 24th, 20:45:14 GMT 

Valid To: 2003 Jul 24th, 20:55:14 GMT 

Subject: MAILTO=SCEP, C=US, ST=MA, L=Andover, 

0=Enterasys Networks, OU=Eng, CN=Scep 
Fingerprint: F1279D63 AFFC3D93 48E5F311 73A1D16F 

Certificate Size: 1695 bytes 

RA Signature Certificate - PKItestcal-ras 
State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 458128729515158954573993 

Issuer: MAILTO=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=VPN Eng, OU=Eng, CN=PKI Test Certificate Authority 
Valid From: 2002 Jul 24th, 20:45:13 GMT 

Valid To: 2003 Jul 24th, 20:55:13 GMT 

Subject: MAILTO=SCEP, C=US, ST=MA, L=Andover, 

0=Enterasys Networks, OU=Eng, CN=Scep 
Fingerprint: 91EB5A77 B5CA535A 077B65C5 65035615 

Certificate Size: 1695 bytes 

Set the CRL retrieval rate and download the latest CRL (optional). 

XSR (conf ig) #crl frequency 12 

XSR (conf ig) #crypto ca crl request PKItestcal 

Add a static host to store IP addresses for use by the CRL mechanism. 

XSR (conf ig) #ip host CRLrepository 223.125.57.88 

Enroll in an end-entity certificate from a CA for which you have previously 
authenticated; e.g., PKItestcal. 

The script will prompt you to enter and re-enter a challenge password 
you create or is given to you by your CA administrator. 
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Remember that if you create a password, save it so it can be used later in 
case you need to revoke the CA. Respond yes to all questions, and jot 
down the certificate serial number for comparison purposes. 

XSR (conf ig) #crypto ca enroll PKItestcal 

% 

% Start certificate enrollment 

% Create a challenge password. You will need to verbally 
provide this password to the CA Administrator in order to 
revoke your certificate. 

For security reasons your password will not be saved in the 

configuration . 

Please make a note of it. 

Password: **** 

Re-enter password:**** 

Include the router serial number in the subject name (y/n) ? y 
The serial number in the certificate will be: 3526015000250142 
Request certificate from CA (y/n) ? y 

You may experience a short delay while RSA keys are generated. 
Once key generation is complete, the certificate request 
will be sent to the Certificate Authority. 
Use 'show crypto ca certificate' to show the fingerprint. 
<186>Aug 29 7:11:1 192.168.1.33 PKI : A certificate was successfully 
received from the CA. 

8 Once the certificate is properly enrolled, issue the show ca 

certificates command to display the end-entity and other certificates. 

The first certificate shown, identified as being in ENTITY- ACTIVE state, 
is the end-entity certificate. Compare the Subject ID to the serial number 
earlier displayed by the enrollment script to verify its authenticity. 

XSR#show crypto ca certificates 

Certificate - issued by PKItestcal 
State : ENTITY-ACTIVE 
Version: V3 

Serial Number: 75289387826578118934757 

Issuer: MAILTO=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=VPN Engineering, OU=Engineering, CN=PKI Test Certificate Authority 
Valid From: 2002 Aug 29th, 15:51:58 GMT 
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Valid To: 2003 Aug 29th, 16:01:58 GMT 

Subject: CN=Enterasys Networks X-pedition Series - 
3526015000250142 

Fingerprint: ABF37B67 7200CCDA 604CB10C D5AC7F49 

Certificate Size: 1590 bytes 

CA Certificate - PKItestcal 
State: CA- AUTHENTICATED 

Version: V3 

Serial Number: 6083 68465503 03 873313 94927502 614112 809 

Issuer: MAILTOsfoo@foo.com, C=US, ST=MA, L=Andover, 

0=VPN Engineering, OU=Engineering, CN=PKI Test Certificate Authority 
Valid From: 2002 Jun 4th, 12:40:46 GMT 

Valid To: 2004 Jun 4th, 12:48:15 GMT 

Subject: MAILT0=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=VPN Engineering, OU=Engineering, CN=PKI Test Certificate Authority 
Fingerprint: D423E129 81904CE0 1E6D0FE0 A123A302 

Certificate Size: 1157 bytes 

RA KeyEncipher Certificate - PKItestcal-rae 
State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 458128935273366930063530 

Issuer: MAILTO=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=VPN Engineering, OU=Engineering, CN=PKI Test Certificate Authority 

Valid From: 2002 Jul 24th, 20:45:14 GMT 

Valid To: 2003 Jul 24th, 20:55:14 GMT 

Subject: MAILTO=SCEP, C=US, ST=MA, L=Andover, 

0=Enterasys Networks, 
OU=Engineering, CN=Scep 

Fingerprint: F1279D63 AFFC3D93 48E5F311 73A1D16F 

Certificate Size: 1695 bytes 

RA Signature Certificate - PKItestcal-ras 

State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 458128729515158954573993 

Issuer: MAILTO=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=VPN Engineering, OU=Engineering, CN=PKI Test Certificate Authority 

Valid From: 2002 Jul 24th, 20:45:13 GMT 

Valid To: 2003 Jul 24th, 20:55:13 GMT 
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Subject: MAILTO=SCEP / C=US, ST=MA, L=Andover / 

0=Enterasys Networks, OU=Engineering, CN=Scep 
Fingerprint: 91EB5A77 B5CA535A 077B65C5 65035615 

Certificate Size: 1695 bytes 

9 Optional. Change the enrollment retry count and period to a value 
matching your CA administrator's needs. 

These values handle "non-pending" mode at the CA when a certificate 
request could time out while waiting for a response. Six requests will be 
issued every 10 minutes. 

XSR (conf ig) #enrollment retry count 6 
XSR (conf ig) #enrollment retry period 10 

Interface VPN Options 

Some configurations require the construct of virtual interfaces that represent 
tunnels on the XSR. A virtual interface defined by the interface vpn 
command often represents IPSec tunnels configured automatically by EZ- 
IPSec. A VPN interface can also be configured as a point-to-point or a point-to- 
multi-point interface with the following conditions: 

□ The interface vpn [#] point- to -point command applies to Site- 
to-Site or EZ-IPSec tunnels initiated by the XSR 

□ The interface vpn [#] multi -point command applies to an XSR 
used as a gateway and tunnel terminator 

VPN Interface Sub-Commands 

The following sub-commands are available at VPN Interface mode: 

ip firewall ^ Set of commands to configure the firewall 
ip address -negotiated 

^ Sets the VPN interface's IP address to be negotiated 

ip address Specifies an IP address on the VPN interface 

ip multicast-redirect ^ Redirects multicast (RIP) to a unicast address 

ip nat Specifies NAT rules on the VPN interface 

ip rip ^ Configures RIP routing on the VPN port 

ip unnumbered 

v& Enables IP processing on a serial port without assigning it an explicit IP address 
ip split-horizon ^ Enables split horizon mechanism 
ip ospf ^ Set of commands to configure OSP+ routing 
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tunnel b®" Names a site-to-site VPN tunnel 

set heartbeat ^ Enables and configures tunnel connectivity monitoring 
set protocol (ipsec) Selects a tunnel protocol 
set active ^ Brings the tunnel up 

set user ^ Designates the user name when initiating a tunnel and obtains 
credentials from the AAA subsystem 

set peer ^ Sets the IP address of the peer 

Configuring a Simple VPN Site-to-Site Application 

The following main steps describe how to configure a simple Site-to-Site VPN 
between two XSRs, as illustrated in Figure 48: 

□ Encrypt Branch-site traffic on the 63.81.66.0/24 network to Central site 
networks (63.81.64.0/24, 63.81.68.0/24, 141.154.196.64/28) 

□ Set up IPSec/IKE policy with pre-shared keys 

□ Configure cryptographic algorithms (transform-sets) and IPSec mode 

□ Configure the VPN interface and crypto maps 
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Figure 48 Site-to-Site Example 



1 Generate a master encryption key as described in "Master Key 
Generation" on page 256. This need only be done once on the router. 

2 Begin Central Site configuration of all necessary physical and system 
requirements, including physical IP addresses, routing (default route and 
RIP or OSPF), and standard ACLs. This example offers numerous options. 

3 Configure Access Lists 120, 130, and 140 to define the particular traffic to 
be protected by the tunnel. The ACLs allow a range of IP addresses on 
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the VPN. In the context of VPN configuration, permit means protector 
encrypt, and deny indicates don't encrypt or allow as is. 

XSR (conf ig) #access-list 120 permit ip 141.154.196.64 
0.0.0.63 63.81.66.0 0.0.0.255 

XSR (conf ig) #access-list 130 permit ip 63.81.64.0 0.0.0.255 
63.81.66.0 0.0.0.255 

XSR (conf ig) #access-list 140 permit ip 63.81.68.0 0.0.0.255 
63.81.66.0 0.0.0.255 

4 Set up IKE Phase 1 protection by entering the following commands: 

XSR (conf ig) #crypto isakmp proposal Test 

Designates ISAKMP proposal Test and acquires ISAKMP mode 
XSR (conf ig- isakmp) #authentication [pre-share | rsa] 

Selects pre-shared key or certificates rsa-sig 
XSR (conf ig- isakmp) #encryption [aes | 3des | des] 

Chooses encryption algorithm 
XSR (conf ig- isakmp) #hash [md5 | shal] 
^ Selects data integrity algorithm 
XSR (conf ig- isakmp) #group [1 | 2 | 5] 

Chooses Diffie-Hellman group 
XSR (conf ig- isakmp) #lif etime < seconds > 

Sets IKE lifetime value 

5 Configure IKE policy for the remote peer. Multiple IKE proposals can be 
configured on each peer participating in IPSec. When IKE negotiation 
begins, it tries to find a common proposal (policy) on both peers with a 
common proposal containing exactly the same encryption, hash, 
authentication, and Diffie-Hellman parameters (lifetime does not 
necessarily have to match). 

XSR (conf ig) #crypto isakmp peer 0.0.0.0 0.0.0.0 

^ Configures the IKE peer IP address/subnet and acquires ISAKMP mode 

XSR (conf ig- isakmp -peer) #proposal Test 

^ Specifies proposal lists testl and test2 

XSR (conf ig-isakmp-peer) #exchange mode [main | aggressive] 
"S* Selects IKE main mode 

XSR (conf ig-isakmp-peer) #nat- traversal [auto | enabled | disabled] 
^ Selects NAT traversal setting 

6 Create a transform-set which adds the specified encryption/data integrity 
algorithms, 768-bit (Group 1) Diffie-Hellman, and your choice of an SA 
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lifetime. You can specify an SA lifetime of seconds and kilobytes - 
whichever value runs out first will cause a rekey. 

XSR (conf ig) #crypto ipsec transform- set esp-3des-sha esp-3des 
esp-sha-hmac Names transform-set with encryption and data integrity values 
XSR (cf g- crypto - tran) #set pfs groupl Set P+S group number 
XSR (cf g- crypto -tran) #set security-association lifetime 
[kilobytes | seconds] Sets SA lifetime in either kilobytes or seconds 

7 Configure three crypto map Test entries which correlate with specified 
transform-sets and ACLs 140, 130 and 120, attach the map to a remote 
peer, configure an independent SA for each traffic stream to a host, and 
select your choice of IPSec mode. Crypto map match statements render 
the associated ACLs bi-directional. 

XSR (conf ig) #crypto map Test 40 
Adds crypto map Test, sequence #40 
XSR (conf ig-crypto-m) #set transform-set esp-3des-sha 
^ Correlates map with the specified transform set 
XSR (conf ig-crypto-m) #match address 140 
^ Applies map to ACL 140 and renders the ACL bi-directional 
XSR (conf ig-crypto-m) #set peer 1.1.1.2 
^ Attaches map to peer 

XSR (conf ig-crypto-m) #mode [tunnel | transport] 
^ Selects IPSec mode for XSR-to-XSR (tunnel) or host to XSR (transport) 
XSR (conf ig-crypto-m) #set security-association level per-host 
^ Sets a separate SA for every traffic flow 
XSR (conf ig) #crypto map Test 2 0 
Adds crypto map Test, sequence #20 
XSR (conf ig-crypto-m) #set transform- set esp-3des esp-sha-hmc 
^ Correlates map with the specified transform set 
XSR (conf ig-crypto-m) #match address 120 
^ Applies map to ACL 120 and renders the ACL bi-directional 
XSR (conf ig-crypto-m) #set peer 1.1.1.3 
^ Attaches map to peer 

XSR (conf ig-crypto-m) #mode [tunnel | transport] 
^ Selects IPSec mode 

XSR (conf ig-crypto-m) #set security-association level per-host 
^ Sets a separate SA for every traffic flow 
XSR (conf ig) #crypto map Test 3 0 
Adds crypto map Test, sequence #30 
XSR (conf ig-crypto-m) #set transform-set esp-des esp-sha-hmc 
^ Correlates map with the specified transform set 
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XSR (conf ig-crypto-m) #match address 130 

^ Applies map to ACL 130 and renders the ACL bi-directional 

XSR (conf ig-crypto-m) #set peer 1.1.1.2 

^ Attaches map to peer 

XSR (conf ig-crypto-m) #mode [tunnel | transport] 
^ Selects IPSec mode 

XSR (conf ig-crypto-m) #set security-association level per-host 
^ Sets a separate SA for every traffic flow 

8 Configuring the XSR VPN interface is the last main task to perform to set 
up the VPN. 

XSR (conf ig) #interf ace fastethernet 2 

"S* Adds FastEthernet port 2 and acquires Interface mode 

XSR (conf ig-if<F2>) #crypto map Test 

^ Attaches Crypto Map to interface and acquires Crypto Map mode 

XSR (conf ig-crypto-m) #description "external interface" 

^ Names the interface 

XSR (conf ig-crypto-m) #ip address 141.154.196.7 8 255.255.255.192 
^ Adds IP address/subnet to interface 
XSR (conf ig-crypto-m) #no shutdown 
v& Enables interface 

Consult the XSR Getting Started Guide for another site-to-site configuration 
example. 

Configuring the VPN Using EZ-IPSec 

The XSR's VPN provides a simple, largely automatic, IPSec configuration 
option called EZ-IPSec which predefines a variety of IKE and IPSec proposals 
and transforms, combining those objects with dynamically-defined Security 
Policy database rules. 

This suite of IPSec and IKE policies, sorted by cryptographic strength, is 
offered to the central gateway which selects one policy based on its local 
configuration. EZ-IPSec also relies upon the IKE Mode Configuration 
protocol to obtain an IP address from the central gateway. 

EZ-IPSec is invoked using the crypto e zip sec command in Interface mode 
to create a set of standard IPSec policies, relieving you of the complex manual 
process. It enables dynamic routing over an IPSec tunnel: 

□ Via Client or Network Extension Mode 
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□ Supporting RIPv2 and OSPF through the tunnel 

The security policy automatically created by crypto e zip sec specifies 
transform-sets for IPSec ESP using 3DES and AES encryption with SHA-1 and 
MD5 integrity algorithms. Also, IPSec SA lifetimes are set to 100 MBytes and 
3600 seconds - whichever value is reached first will cause a rekey 

EZ-IPSec configuration is comprised of two components: 

□ Enabling EZ-IPSec security policies and attaching to a network 
interface using crypto ezipsec configured on any interface other 
than FastEthernet/ GigabitEthernet 1 

□ Defining a virtual interface (VPN) in point-to-point mode which 
initiates a tunnel to a gateway XSR 

EZ-IPSec Configuration 

The commands below are used to configure a VPN interface on the XSR. The 
set protocol ipsec command is needed to select the following modes: 

□ Client Mode. The virtual interface (interface vpn #) is assigned an 
address using Mode Config and an IPSec security policy rule is 
inserted into the external interface's SPD securing traffic to and from 
that address. NATP is enabled on the VPN interface. 

□ Network Extension Mode. Same as client mode except NAPT is disabled 
on the VPN interface and two crypto map entries are added to the 
external interface SPD. One rule secures traffic to the virtual interface's 
assigned address and the other secures traffic to the trusted network 
interface which is assumed to be FastEthernet 1. 

The commands below require manual configuration in conjunction with the 
crypto ezipsec command: 

□ interface vpn [1 -255] 

□ ip address negotiated 

□ tunnel [Tunnel Name] 

□ set user [username | certificate] 

□ set peer [My Remote VPN Server Address] 

□ set protocol ipsec [client-mode | network -extension -mode] 

For example, configure the following Network Extension Mode tunnel: 
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XSR (conf ig) #interf ace vpn 1 point-to-point 
^ Sets VPN interface 1 to initiate a tunnel connection and acquires VPN interface 
mode. You must always set a Point-to-Point tunnel at the remote site and Point-to- 
Multipoint tunnel at the central site 

XSR (conf ig-int-vpn) #ip address negotiated 

^ Asks for dynamic virtual IP address assignment of this VPN interface by its peer 
XSR (conf ig-int-vpn) #tunnel Corporate 
^ Names the site-to-site tunnel Corporate 

XSR (conf ig-tms- tunnel) #set user My_Remote_site 

^ Indicates a pre-share key is being used. You must add an EZ-IPSec tunnel using 

the password of this user in the AAA database 

XSR (conf ig-tms -tunnel) #set peer 200.10.20.30 

Specifies the IP address of the remote peer 
XSR (conf ig-tms- tunnel) #set protocol ipsec network- extension -mode 
<®* Selects IPSec to initiate a NEM tunnel connection 

^ NOTE 

Pre-shared key proposals are used if a user name is supplied with a 
tunnel. If no user name is supplied, EZ-IPSec verifies the XSR has one or 
more valid certificates and it uses RSA signature authentication. 



Most of the parameters shown below have been automatically entered by 
EZ-IPSec. Be aware that they do not appear in the running-config file. 

crypto isakmp peer 200.10.20.30/32 

proposal ez-ike-3des-sha-psk ez-ike-3des-md5-psk 

config-mode client 

exchange -mode aggressive 

nat- traversal automatic 

crypto map ez- ipsec 100 

match address 100 

set peer 200.10.20.30 

mode tunnel 

set transform-set ez-esp-3des-sha-pf s ez-esp-3des-md5-pf s 

set transform-set ez-esp-aes-sha-pf s ez-esp-aes-md5-pf s 

set transform-set ez -esp-3des- sha-no-pf s ez-esp-3des-md5-no-pf s 

set transform-set ez-esp-aes-sha-no-pf s ez-esp-aes-md5-no-pf s 

crypto map ez- ipsec 101 

match address 101 

set peer 200.10.20.30 
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XSR with VPN - Central Gateway 

In this scenario, as illustrated in Figure 49, a Central VPN gateway is 
configured to perform the following: 

□ Terminate NEM and Client mode tunnels 

□ Terminate remote access L2TP/IPSec tunnels 

□ Terminate PPTP remote access tunnels 

□ OSPF routing with the next hop corporate router on the trusted VPN 
interface 

□ DF bit clear on the public VPN interface to handle large non- 
fragmentable IP frames 

□ OSPF routing over the multi-point VPN interface for other site-to-site 
tunnels 

□ Assign the first IP address of the pool to the multi-point VPN interface. 
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Figure 49 EZ-IPSec Client, XP Client and Gateway Topology 
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Begin by setting the XSR system time via SNTP. This configuration is critical 
for XSRs which use time-sensitive certificates. 

XSR (conf ig) #sntp-client server 10.120.84.3 
XSR (conf ig) #sntp-client poll-interval 60 

Add ACLs to permit IP and UDP traffic: 

XSR (conf ig) #access-list 130 permit udp any any eq 500 
XSR (conf ig) #access-list 130 permit gre any any 
XSR (conf ig) #access-list 130 permit tcp any any est 
XSR (conf ig) #access-list 130 permit tcp any any eq 1723 
XSR (conf ig) #access-list 130 deny ip any any 

Add ACLs for IP local pool/EZ-IPSec, Network Extension address and L2TP: 

XSR (conf ig) #access-list 110 permit ip any 10.120.70.0 0.0.0.255 
XSR (conf ig) #access-list 120 permit udp any any eq 1701 
XSR (conf ig) #access-list 140 permit ip any 172.16.1.0 0.0.0.255 
XSR (conf ig) #access-list 150 permit ip any 192.168.111.0 0.0.0.255 

Define IKE Phase I security parameters with the following two policies: 

XSR (conf ig) #crypto isakmp proposal xp-soho 

XSR (conf ig-isakmp) #hash md5 

XSR (conf ig-isakmp) #lifetime 50000 

XSR (conf ig) #crypto isakmp proposal p2p 

XSR (conf ig-isakmp) #authentication pre-share 

XSR (conf ig-isakmp) #lifetime 50000 

Configure IKE policy for the remote peer: 

XSR (conf ig) #crypto isakmp peer 0.0.0.0 0.0.0.0 
XSR (conf ig-isakmp-peer) #proposal xp-soho p2p 
XSR (conf ig-isakmp-peer) #conf ig-mode gateway 
XSR (conf ig-isakmp-peer) #nat- traversal automatic 

Configure the following four IPSec SAs: 

XSR (conf ig) #crypto ipsec transform-set esp-3des-md5 esp-3des 
esp-md5-hmac 

XSR (cfg-crypto- tran) no set security-association lifetime kilobytes 

XSR (conf ig) #crypto ipsec transform-set esp-3des-sha esp-3des 
esp-sha-hmac 
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XSR (cf g-crypto- tran) set security-association lifetime kilobytes 
10000 

Configure the following four crypto maps to match ACLs 150, 140, 120, and 110: 
XSR (conf ig) #crypto map test 50 

XSR (conf ig-crypto-m) #set transform-set esp-3des-sha 
XSR (conf ig-crypto-m) #match address 150 

XSR (conf ig) #crypto map test 40 

XSR (conf ig-crypto-m) #set transform-set esp-3des-sha 
XSR (conf ig-crypto-m) #match address 140 

XSR (conf ig) #crypto map test 20 

XSR (conf ig-crypto-m) #set transform-set esp-3des-md5 
XSR (conf ig-crypto-m) #match address 120 
XSR (conf ig-crypto-m) #mode transport 

XSR (conf ig-crypto-m) #set security-association level per-host 
XSR (conf ig) #crypto map test 10 

XSR (conf ig-crypto-m) #set transform-set esp-3des-sha 
XSR (conf ig-crypto-m) #match address 110 

Configure and enable the FastEthernet 1 interface: 

XSR (conf ig) #interf ace FastEthernetl 

XSR (conf ig-if <F1>) #ip address 10.120.112.0/24 

XSR (conf ig-if <F1>) #no shutdown 

Configure FastEthernet interface 2 with the attached crypto map test: 

XSR (conf ig) #interface FastEthernet2 
XSR (conf ig-if <F2>) #crypto map test 

XSR(config-if<F2>) #ip address 141.154.196.87 255.255.255.192 
XSR (conf ig-if <F2>) #access -group 130 in 
XSR (conf ig-if <F2>) #access-group 130 out 
XSR (conf ig-if <F2>) #no shutdown 

Configure the VPN virtual interface as a terminating tunnel server with IP 
multicast redirection back to the gateway, add an OSPF network with cost 
and disable the firewall: 

XSR (conf ig) #interf ace Vpnl multi-point 

XSR (conf ig-int-vpn) #ip multicast-redirect tunnel -endpoint 
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XSR (conf ig-int-vpn) #f irewall disable 

XSR(config-int-vpn) #ip address 10.120.70.1 255.255.255.0 
XSR (conf ig-int-vpn) #ip ospf priority 10 
XSR (conf ig-int-vpn) #ip ospf network nbma 

Add a default route to the next hop Internet gateway: 

XSR (conf ig)#ip route 0.0.0.0 0.0.0.0 141.154.196.93 

Define an IP pool for distribution of tunnel addresses to all client types: 
XSR (conf ig) #ip local pool test 10.120.70.0/24 

Create hosts to resolve hostnames for the certificate servers for CRL retrieval: 

XSR (conf ig) #ip host parentca 141.154.196.89 
XSR (conf ig) #ip host childca2 141.154.196.81 
XSR (conf ig) #ip host childcal 141.154.196.83 

Clear the DF bit globally: 

XSR (conf ig) #crypto ipsec df-bit clear 

Enable the OSPF engine, VPN and FastEthernet 1 interfaces for routing: 
XSR (conf ig) #router ospf 1 

XSR (conf ig-router) #network 10.120.70.0 0.0.0.255 area 5.5.5.5 
XSR (conf ig-router) #network 10.120.112.0 0.0.0.255 area 5.5.5.5 

Create a group for NEM and Client mode users: 
XSR (conf ig) #aaa group sohoclient 

XSR (aaa-group) #dns server primary 10.120.112.220 

XSR (aaa-group) #dns server secondary 0.0.0.0 

XSR (aaa-group) #wins server primary 10.120.112.220 

XSR (aaa-group) #wins server secondary 0.0.0.0 

XSR (aaa-group) #ip pool test 

XSR (aaa-group) #pptp compression 

XSR (aaa-group) #pptp encrypt mppe 128 

XSR (aaa-group) #12tp compression 

XSR (aaa-group) #policy vpn 

Define a group for remote access XP users including DNS and WINs servers, 
an IP pool, PPTP and L2TP values, and client VPN permission: 

XSR (conf ig) #aaa group XPusers 

XSR (aaa-group) #dns server primary 10.120.112.220 
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XSR (aaa-group) #dns server secondary 0.0.0.0 

XSR (aaa-group) #wins server primary 10.120.112.220 

XSR (aaa-group) #wins server secondary 0.0.0.0 

XSR (aaa-group) #ip pool test 

XSR (aaa-group) #pptp compression 

XSR (aaa-group) #pptp encrypt mppe 128 

XSR (aaa-group) #12tp compression 

XSR (aaa-group) #policy vpn 

Configure the RADIUS AAA method to authenticate remote access users: 

XSR (conf ig) #aaa method radius msradius default 

XSR (aaa-method-radius) #backup test 

XSR (aaa-method-radius) #enable 

XSR (aaa-method-radius) #group DEFAULT 

XSR (aaa-method-radius) #address ip-address 10.120.112.179 

XSR (aaa-method-radius) #key welcome 

XSR (aaa-method-radius) #auth-port 1812 

XSR (aaa-method-radius) #acct-port 1646 

XSR (aaa-method-radius) #attempts 1 

XSR (aaa-method-radius) #retransmit 1 

XSR (aaa-method-radius) #timeout 5 

XSR (aaa-method-radius) #qtimeout 0 

Configure the branch office EZ-IPSec on the PPPoEe, FastEthernet sub- 
interface 2.2, using certificates for authentication: 

XSR (conf ig) # interface FastEthernet 1 

XSR(config-if<Fl>) #ip address 172.16.1.1 255.255.255.0 
XSR (conf ig-if <F1>) #no shutdown 

XSR (conf ig) # interface FastEthernet 2 

XSR (conf ig-if <F2>) #no shutdown 

XSR (conf ig) #interf ace fastethernet 2.2 

XSR (conf ig-if ) #crypto ezipsec 

XSR (conf ig-if ) #enc ppp 

XSR (conf ig-if ) #ip address negociated 

XSR(conf ig-if ) #ip mtu 1492 

XSR (conf ig-if ) #ip nat source assigned overload 

XSR (conf ig-if ) #ppp pap sent-username pezhmon password pezhmon 
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Configure the Network Extension Mode tunnel, site-to-site IPSec tunnel to 
the central site XSR (Robo6). 

XSR (conf ig) #interf ace vpn 1 point-to-point 

XSR (conf ig-int-vpn) #ip address neg 

XSR (conf ig-int-vpn) #tunnel Pipe 

XSR (conf ig-tms- tunnel) #set user certificate 

XSR (conf ig-tms- tunnel) #set protocol ipsec network 

XSR (conf ig-tms- tunnel) #set active 

XSR (conf ig-tms -tunnel) #set peer 141.154.196.86 

XSR (conf ig-int-vpn) # ip ospf cost 110 

XSR (conf ig-int-vpn) #ip ospf priority 0 

XSR (conf ig-int-vpn) #ip ospf network nbma 

XSR (conf ig) #ip route 0.0.0.0 0.0.0.0 FastEthernet 2.2 

Create hosts to resolve hostnames for the certificate servers for CRL retrieval: 

XSR (conf ig) #ip host parentca 141.154.196.89 
XSR (conf ig) #ip host childca2 141.154.196.81 
XSR (conf ig) #ip host childcal 141.154.196.83 

Enable the OSPF engine, VPN (Central site pool) and FastEthernet 1 interfaces 
for routing: 

XSR (conf ig) #router ospf 1 

XSR (conf ig-router) #network 10.120.70.0 0.0.0.255 area 5.5.5.5 
XSR (conf ig-router) #network 172.16.1.0 0.0.0.255 area 5.5.5.5 

Consult the XSR Getting Started Guide for another NEM configuration 
example. 

XSR/Cisco Site-to-Site Example 

The following Site-to-Site configuration connects a Cisco 2600 router with 
internal/external IP addresses of 192.168.3.5/192.168.2.5 to a XSR with 
internal /external IP addresses of 192.168.1.2/192.168.2.2. The commands are 
displayed as they would appear when displayed in the configuration file. 

Cisco Configuration 

version 12.2 

service times tamps debug uptime 
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service time stamps log uptime 
no service password-encryption 

hostname Cisco2600 

enable secret 5 $1$91 j t$kg86F7Ylvsa2NpOZ j 5wDf 1 
enable password welcome 

ip subnet -zero 

ip host spatel 192.168.1.1 

crypto isakmp policy 1 
hash md5 

authentication pre-share 
group 2 
lifetime 1200 

crypto isakmp policy 2 0 
hash md5 

authentication pre-share 
lifetime 1200 

crypto isakmp key welcome address 192.168.2.2 

crypto ipsec security-association lifetime seconds 1800 

crypto ipsec transform-set esp-des-md5 esp-des esp-md5-hmac 

crypto map regular 1 ipsec -isakmp 
set peer 192.168.2.2 

set security-association lifetime kilobytes 10000 
set security-association lifetime seconds 7200 
set transform-set esp-des-md5 
set pfs group2 
match address 110 

fax interface- type fax-mail 

mta receive maximum- recipients 0 
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interface FastEthernetO/0 

ip address 192.168.3.5 255.255.255.0 

speed auto 

half -duplex 

no cdp enable 

interface FastEthernetO/1 

ip address 192.168.2.5 255.255.255.0 

duplex auto 

speed auto 

no cdp enable 

crypto map regular 

ip classless 

ip route 0.0.0.0 0.0.0.0 192.168.2.1 

ip route 192.168.1.0 255.255.255.0 192.168.2.2 

ip http server 

ip pirn bidir-enable 

access-list 110 permit ip 192.168.3.0 0.0.0.255 192.168.1.0 
0.0.0.255 

dialer-list 1 protocol ip permit 
dialer-list 1 protocol ipx permit 

snmp- server group testgroup v3 auth 
snmp- server community public RO 
call rsvp-sync 

mgcp profile default 

dial-peer cor custom 

line con 0 
exec -timeout 0 0 
line aux 0 
line vty 0 4 
password welcome 
login 
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XSR Configuration 

XSR (conf ig) #access-list 120 permit ip 192.168.3.0 0.0.0.255 
192.168.1.0 0.0.0.255 

XSR (conf ig) #crypto isakmp proposal test 
XSR (conf ig- isakmp) #authentication pre -share 
XSR (conf ig- isakmp) #encryption des 
XSR (conf ig- isakmp) #hash md5 

XSR (conf ig) #crypto isakmp peer 0.0.0.0 0.0.0.0 
XSR (conf ig- isakmp -peer) #proposal test 

XSR (conf ig) #cry ips trans esp-des-md5 esp-des esp-md5-hmac 
XSR (cf g- crypto - t ran) #set pfs group2 

XSR (cf g- crypto - t ran) #no set security-association life kilo 
XSR (cfg- crypto- t ran) #set security-association life secon 700 

XSR (conf ig) #crypto map test 20 

XSR (conf ig-crypto-m) #set transform-set esp-des-md5 
XSR (conf ig-crypto-m) #match address 120 
XSR (conf ig-crypto-m) #set peer 192.168.2.5 
XSR (conf ig-crypto-m) #mode tunnel 

XSR (conf ig) #interf ace fastethernet 1 
XSR (conf ig-if <F1>) #no shutdown 

XSR(config-if<Fl>) #ip address 192.168.1.2 255.255.255.0 

XSR (conf ig) #interf ace fastethernet 2 
XSR (conf ig-if <F2>) #crypto map test 
XSR (conf ig-if <F2>) #no shutdown 

XSR(config-if<F2>) #ip address 192.168.2.2 255.255.255.0 

XSR (conf ig)#ip route 192.168.3.0 255.255.255.0 192.168.2.5 
XSR (conf ig) #ip route 0.0.0.0 0.0.0.0 192.168.2.1 

XSR (conf ig) #snmp- server disable 
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Scenario 1 : Gateway-to-Gateway with Pre-Shared Secrets 

This section describes how to configure the XSR according to the VPN 
Consortium's interoperability scenarios (http:/ /www. vpnc.org/). The 
following is a typical gateway-to-gateway VPN that uses a pre-shared secret 
for authentication, as illustrated in Figure 50. 
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172.23.9.0/24 




Internet 



AW 
14.15.16.17 




BW 
22.23.24.25 



BL 

172.23.9.1 



Figure 50 Gateway-toGateway with Pre-Shared Secrets Topology 



Gateway A connects the internal LAN 10.5.6.0/24 to the Internet. Gateway 
A's LAN interface has the address 10.5.6.1, and its WAN (Internet) interface 
has the address 14.15.16.17. 

Gateway B connects the internal LAN 172.23.9.0/24 to the Internet. Gateway 
B's WAN (Internet) interface has the address 22.23.24.25. Gateway B's LAN 
interface address, 172.23.9.1, can be used for testing IPsec but is not needed 
for configuring Gateway A. 

The IKE Phase 1 parameters used in Scenario 1 are: 

□ Main mode 

□ Triple DES 

□ SHA-1 

□ MODP group 2 (1024 bits) 

□ Pre-shared secret of // hr5xb8416aa9r6 ,/ 

□ SA lifetime of 28800 seconds (eight hours) with no Kbytes rekeying 

The IKE Phase 2 parameters used in Scenario 1 are: 

□ Triple DES 
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□ SHA-1 

□ ESP tunnel mode 

□ MODP group 2 (1024 bits) 

□ Perfect forward secrecy for rekeying 

□ SA lifetime of 3600 seconds (one hour) with no Kbytes rekeying 

□ Selectors for all IP protocols, all ports, between 10.5.6.0/24 and 
172.23.9.0/24, using IPv4 subnets 

This configuration assumes you have already set up the XSR for basic 
operations (refer to the XSR Getting Started Guide). Also, you should have 
generated a master key (see the XSR User Guide). To set up Gateway A for this 
scenario, perform the following steps on the CLI: 

1 Configure the Gateway A internal LAN network (AL): 

XSR (conf ig) #interf ace FastEthernetl 
XSR (conf ig-if <F1>) #no shutdown 

XSR(config-if<Fl>) #ip address 10.5.6.1 255.255.255.0 

2 Configure the Gateway A external LAN network (AW): 

XSR (conf ig) #interf ace FastEthernet2 
XSR (conf ig-if <F1>) #no shutdown 

XSR(config-if<Fl>)#ip address 14.15.16.17 255.255.255.0 

3 Configure a simple, wide-open access list to permit all traffic from the 
source to the destination network: 

XSR (conf ig) #access-list 101 permit ip 10.5.6.0 0.0.0.255 
172.23.9.0 0.0.0.255 

4 Configure a default route: 

XSR (conf ig) #ip route 0.0.0.0 0.0.0.0 14.15.16.1 

5 Configure IKE Phase 1 policy: 

XSR (conf ig) #crypto isakmp proposal Safe 

XSR (conf ig- isakmp) #authentication pre -share 

XSR (conf ig- isakmp) #encryption 3des 

XSR (conf ig- isakmp) #hash sha 

XSR (conf ig- isakmp) #group 2 

XSR (conf ig-isakmp) #lifetime 28800 
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6 Configure IKE policy Safe for the Gateway B remote peer. Optionally, 
multiple IKE proposals can be configured on each peer participating in 
IPSec. 

XSR(conf ig) #crypto isakmp peer 22.23.24.25 255.255.255.255 

XSR (config- isakmp -peer) #proposal Safe 

XSR (config- isakmp -peer) #conf ig-mode gateway 

XSR (config- isakmp-peer) #exchange-mode main 

7 Configure IKE Phase 2 settings by creating the transform-set Secure: 

XSR (config) #crypto ipsec transform-set Secure esp-3des esp- 
shal-hmac 

XSR (cf g- crypto - t ran) #set pfs group2 

XSR (cf g- crypto - t ran) #set security-association lifetime 
seconds 3600 

8 Configure the crypto map Highflow which correlates with transform-set 
Secure and access list 101 , and attach the map to the remote peer. 

XSR (config) #crypto map Highflow 1 
XSR (conf ig-crypto-m) #set trans form- set Secure 
XSR (conf ig-crypto-m) #match address 101 
XSR (conf ig-crypto-m) #set peer 22.23.24.25 

9 Attach the crypto map Highflow to the Gateway A external interface (AW): 

XSR (config) #interface FastEthernet2 
XSR (conf ig-if <F2>) #crypto map Highflow 
XSR (conf ig-if <F2>) #no shutdown 

10 Configure the pre-shared key. The username is the IP address of the peer 
and the password is the pre-shared key. 

XSR (conf ig) #aaa user 22.23.24.25 

XSR (aaa-user) #password hr5xb8416aa9r6 

11 Test the connection by pinging a PC on the 172.23.9.0 network from the 
10.5.6.0 network. Alternately, pinging the PC from Gateway A, if 
successful, will produce the output shown below. Be aware that for a ping 
to traverse the tunnel, you must configure an ACL with the host source 
and host destination IP addresses. 

XSR#ping 172.23.9.5 
Type escape sequence to abort 
Reply from 172.23.9.5: 20ms 
Reply from 172.23.9.5: 10ms 
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Reply from 172.23.9.5: 10ms 
Reply from 172.23.9.5: 10ms 
Reply from 172.23.9.5: 10ms 
Packets: Sent = 5, Received = 5, Lost = 0 

You can also issue the following show commands to examine Phase 1 and 
Phase 2 settings, respectively. When the tunnel is up, the commands will 
display the following output: 

XSR#show crypto isakmp sa 

Connection-ID State Source Destination Lifetime 



4561 QM_IDLE 14.15.16.17 22.23.24.25 28000 

XSR#show crypto ipsec sa 

14.15.16.0/24, ANY, 0 ==> 22.23.24.0/24, ANY, 0 : 92 packets 
ESP: SPI=190dlf5f , Trans f orm=3DES/HMAC- SHA, Lif e=3 600S/0KB 



Scenario 2: Gateway-to-Gateway with Certificates 

The following is a typical gateway-to-gateway VPN that uses certificates for 
authentication, as illustrated in Figure 51. 
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Figure 51 Gateway-toGateway with Certificates Topology 



Gateway A connects the internal LAN 10.5.6.0/24 to the Internet. Gateway 
A's LAN interface has the address 10.5.6.1, and its WAN (Internet) interface 
has the address 14.15.16.17. 
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Gateway B connects the internal LAN 172.23.9.0/24 to the Internet. Gateway 
B's WAN (Internet) interface has the address 22.23.24.25. Gateway B's LAN 
interface address, 172.23.9.1, can be used for testing IPsec but is not needed 
for configuring Gateway A. 

The IKE Phase 1 parameters used in Scenario 2 are: 

□ Main mode 

□ Triple DES 

□ SHA-1 

□ MODP group 2 (1024 bits) 

□ SA lifetime of 28800 seconds (eight hours) with no Kbytes rekeying 

The IKE Phase 2 parameters used in Scenario 2 are: 

□ Triple DES 

□ SHA-1 

□ ESP tunnel mode 

□ MODP group 2 (1024 bits) 

□ Perfect forward secrecy for rekeying 

□ SA lifetime of 3600 seconds (one hour) with no Kbytes rekeying 

□ Selectors for all IP protocols, all ports, between 10.5.6.0/24 and 
172.23.9.0/24, using IPv4 subnets 

This configuration assumes you have already set up the XSR for basic 
operations (refer to the XSR Getting Started Guide). Also, you should have 
generated a master key (see the XSR User Guide). To set up Gateway A for this 
scenario, perform the same steps as you would perform in Scenario 1, with 
one exception. 

In Step 5, for authentication, select RSA signatures as follows: 
XSR (conf ig-isakmp) #authentication rsa-sig 

After completing all 11 steps to configure the VPN, obtain a Root CA and 
personal certificate for this scenario by performing the following steps: 

1 Begin by asking your CA administrator for your CA name and URL. The 
CA's URL defines its IP address, path and default port (80). You can 
resolve the CA server address manually by pinging its IP address. 
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2 Be sure that the XSR time setting is correct according to the UTC time 
zone so that it is synchronized with the CA's time. For example: 

XSR) #clock timezone -7 0 

3 Specify the enrollment URL, authenticate the CA and retrieve the root 
certificate. Check your CA Website to ensure that the printed fingerprint 
matches the CA's fingerprint, which is retrieved from the CA itself, to 
verify the CA is not a fake. If bona fide, accept the certificate, if not, check 
to be sure the certificate is deleted and not stored in the CA database. In 
certain situations you may need to specify a particular CA identity name. 
Consult your administrator for more information. 

XSR (conf ig) #crypto ca identity Hightest 
XSR (conf ig-ca- identity) #enrollment url 
http: //192 . 168 . 1 . 33/certsrv/mscep/mscep . dll/ 
XSR (conf ig-ca -identity) #exit 

XSR (conf ig) #crypto ca authenticate PKItestcal 

Certificate has the following attributes: 
Fingerprint: D423E129 81904CE0 1E6D0FE0 A123A302 
Do you accept this certificate? [yes/no] y 

4 Display your CA certificates to verify all root and associated certificates 
are present. In the RA Mode example below, Hightest is the root CA of 
three certificates. Non-RA Mode CAs return one certificate only. 

XSR (conf ig) #show crypto ca certificates 

CA Certificate - Hightest 
State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 6083 6846550303873313 94927502 614112809 

Issuer: MAILTO=f oo@f oo . com, C=US , ST=MA, 

L=Andover, 0=Ent Sys, OU=Sales, CN=PKI Certificate Authority 
Valid From: 2002 Jun 4th, 12:40:46 GMT 

Valid To: 2004 Jun 4th, 12:48:15 GMT 

Subject: MAILTO=f oo@f oo . com, C=US, ST=MA, 

L=Andover, 0=Ent Sys, OU=Sales, CN=PKI Certificate Authority 
Fingerprint: D423E129 81904CE0 1E6D0FE0 A123A302 

Certificate Size: 1157 bytes 

RA KeyEncipher Certificate - Hightest-rae 
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State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 458128935273366930063530 
Issuer: MAILTO=f oo@f oo . com, C=US, ST=MA, 

L=Andover, 0=Ent Sys, 0U=Sales, CN=PKI Certificate Authority 
Valid From: 2002 Jul 24th, 20:45:14 GMT 

Valid To: 2003 Jul 24th, 20:55:14 GMT 

Subject: MAILTO=SCEP, C=US, ST=MA, L=Andover, 

0=Enterasys Networks, OU=Sales, CN=Scep 
Fingerprint: F1279D63 AFFC3D93 48E5F311 73A1D16F 

Certificate Size: 1695 bytes 

RA Signature Certificate - Hightest-ras 
State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 458128729515158954573993 
Issuer: MAILTO=f oo@f oo . com, C=US, ST=MA, 

L=Andover, 0=Ent Sys, OU=Sales, CN=PKI Certificate Authority 
Valid From: 2002 Jul 24th, 20:45:13 GMT 

Valid To: 2003 Jul 24th, 20:55:13 GMT 

Subject: MAILTO=SCEP, C=US, ST=MA, L=Andover, 

0=Ent Sys, OU=Sales, CN=Scep 
Fingerprint: 91EB5A77 B5CA535A 077B65C5 65035615 

Certificate Size: 1695 bytes 

5 Enroll in an end-entity certificate from a CA for which you have previously 
authenticated; e.g., Hightest. 

The script will prompt you to enter and re-enter a challenge password 
you create or is given to you by your CA administrator. Remember that if 
you create a password, save it so it can be used later in case you need to 
revoke the CA. Respond yes to all questions, and jot down the certificate 
serial number for comparison purposes. 

XSR (conf ig) #crypto ca enroll Hightest 

% 

% Start certificate enrollment 

% Create a challenge password. You will need to verbally 
provide this password to the CA Administrator in order to 
revoke your certificate. 
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For security reasons your password will not be saved in the 

configuration . 

Please make a note of it. 

Password: **** 

Re-enter password:**** 

Include the router serial number in the subject name (y/n) ? 

y 

The serial number in the certificate will be: 
3526015000250142 

Request certificate from CA (y/n) ? y 

You may experience a short delay while RSA keys are 

generated. 

Once key generation is complete, the certificate request 

will be sent to the Certificate Authority. 

Use 'show crypto ca certificate' to show the fingerprint. 

<186>Aug 29 7:11:1 192.168.1.33 PKI : A certificate was 

successfully 

received from the CA. 

Once the certificate is properly enrolled, issue the show crypto ca 
certificates command to display the end-entity and other certificates. 

The first certificate shown, identified as being in ENTITY- ACTIVE state, 
is the end-entity certificate. Compare the Subject ID to the serial number 
earlier displayed by the enrollment script to verify its authenticity. 

XSR#show crypto ca certificates 

Certificate - issued by Hightest 
State : ENTITY-ACTIVE 
Version: V3 

Serial Number: 75289387826578118934757 

Issuer: MAILTOsfoo@foo.com, C=US, ST=MA, L=Andover, 

0=Ent Sys, 0U=Sales / CN=PKI Certificate Authority 

Valid From: 2002 Aug 29th, 15:51:58 GMT 

Valid To: 2003 Aug 29th, 16:01:58 GMT 

Subject: CN=Enterasys Networks X-pedition Series - 

3526015000250142 

Fingerprint: ABF37B67 7200CCDA 604CB10C D5AC7F49 

Certificate Size: 1590 bytes 



XSR User's Guide 



293 



Interoperability Profile for the XSR 



Chapter 11 

Configuring the Virtual Private Network 



CA Certificate - PKItestcal 
State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 60 83 68465503 03 873313 94 927502 614112 80 9 

Issuer: MAILTOsfoo@foo.com, C=US, ST=MA, L=Andover, 

0=Ent Sys, 0U=Sales / CN=PKI Certificate Authority 
Valid From: 2002 Jun 4th, 12:40:46 GMT 

Valid To: 2004 Jun 4th, 12:48:15 GMT 

Subject: MAILT0=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=Ent Sys, 0U=Sales, CN=PKI Certificate Authority 
Fingerprint: D423E129 81904CE0 1E6D0FE0 A123A302 

Certificate Size: 1157 bytes 



RA KeyEncipher Certificate - Hightest-rae 
State: CA- AUTHENTICATED 

Version: V3 

Serial Number: 458128935273366930063530 

Issuer: MAILT0=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=Ent Sys, 0U=Sales, CN=PKI Certificate Authority 
Valid From: 2002 Jul 24th, 20:45:14 GMT 

Valid To: 2003 Jul 24th, 20:55:14 GMT 

Subject: MAILTO=SCEP, C=US, ST=MA, L=Andover, 0=Ent 

Sys,OU=Sales, CN=Scep 
Fingerprint: F1279D63 AFFC3D93 48E5F311 73A1D16F 

Certificate Size: 1695 bytes 

RA Signature Certificate - Hightest-ras 
State : CA- AUTHENTICATED 

Version: V3 

Serial Number: 458128729515158954573993 

Issuer: MAILT0=f oo@f oo . com, C=US, ST=MA, L=Andover, 

0=Ent Sys, OU=Sales, CN=PKI Certificate Authority 
Valid From: 2002 Jul 24th, 20:45:13 GMT 

Valid To: 2003 Jul 24th, 20:55:13 GMT 

Subject: MAILTO=SCEP, C=US, ST=MA, L=Andover, 0=Ent 

Sys, OU=Sales, CN=Scep 
Fingerprint: 91EB5A77 B5CA535A 077B65C5 65035615 

Certificate Size: 1695 bytes 
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Overview of DHCP 

The Dynamic Host Configuration Protocol (DHCP) allocates and delivers 
configuration values, including IP addresses, to Internet hosts. Consisting of 
of two components, DHCP provides host-specific configuration parameters 
from a DHCP Server to a host, and allocates network addresses to hosts. 
Recent extensions to the DHCP protocol extends high-availability, 
authenticated and QoS-dependent configuration of Internet hosts. 

DHCP is based on the client-server model - a designated DHCP Server 
allocates network addresses and delivers configuration values to dynamically 
configured clients. Throughout this chapter, the term server refers to a host 
providing initialization values via DHCP, and the term client refers to a host 
requesting initialization values from a DHCP Server. 

DHCP allocates IP addresses in two ways: 

□ Dynamic allocation assigns an IP address to a client for a limited 
interval - lease - (or until a client explicitly relinquishes its address). 

□ Manual allocation involves a client IP address assigned by the 
network administrator, with DHCP used simply to convey the 
assigned address to the client. 

DHCP messages are formatted similar to BOOTP messages to capture BOOTP 
Relay Agent behavior and allow existing BOOTP clients to interoperate with 
DHCP servers. DHCP is backward compatible with BOOTP (RFC-951). 
Implemented as an improvement to BOOTP, DHCP differs from BOOTP by 
its dynamically IP address allocation and lease definition capabilities. 
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Features 

The XSR offers the DHCP features: 

□ Persistent storage/ database of network values for network clients. 

□ Persistent storage of network client lease states kept across reboot. 

□ Temporary or permanent network (IP) address allocation to clients. 

□ Network configuration parameter assignment to clients. 

□ Provisioning of differentiated network values by Client Class 

□ Persistent and user-controllable conflict avoidance to prevent 
duplicate IP address including configurable ping checking. 

□ Visibility of DHCP network activity and leases through operator 
reports statistics and logs. 

□ Nested scopes 

DHCP Server Standards 

The XSR supports the following: 

□ DHCP Server as defined in RFC-2131, BOOTP Server and BOOTP 
Relay as defined in RFC-951/RFC-1542, and BOOTP Client as defined 
in RFC-1534: Inter operation Between DHCP and BOOTP (static BOOTP 
only) 

□ DHCP Server also supports RFC-2132: DHCP Options and BOOTP 
Vendor Extensions and RFC-3004: User Class Option for DHCP. 

□ DHCP Server and DHCP /BOOTP Relay services run on FastEthernet 
ports only. 

If either DHCP /BOOTP Relay (using the ip helper -address command) 
or DHCP Server is enabled on one FastEthernet port, you cannot also 
configure the other service on the second FastEthernet port. The 
XSR permits either one or the other service to operate, not both. 
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How DHCP Works 

DHCP's client-server model defines a set of messages exchanged between 
two systems. A simplified description client-server communications follows: 

1 A client issues a broadcast message (DISCOVER) to locate available 
DHCP Servers on its local subnet. This message may include 
suggested values for the network address and duration of a lease. 
Also, BOOTP relay agents may pass the message on to DHCP 
Servers not on the same physical subnet. 

2 A response (OFFER) is sent from a DHCP Server to the client with an 
offer of configuration parameters including an available network IP 
address, among others. Before the server actually allocates the new 
address, it will check that the address is free by pinging it. 

3 A client sends a message (REQUEST) to servers for one of the 
following purposes: 

- Requesting offered parameters from one server and implicitly 
declining offers from all others, 

- Confirming the correctness of a previously allocated address 
after, for example, a system reboot, 

- Extending the lease on a particular network address. 

4 The selected server sends a message (ACK) to a client with 
configuration parameters - a binding - including a committed network 
address, client-identifier or hardware-address and commits its lease 
to the binding database. Or, the server sends a message (NACK) 
indicating the client's idea of a network address is incorrect or the 
client's lease has expired. 

5 The client performs a final check (ARPs the allocated network 
address) on the parameters and at this point is configured. 

6 The client may relinquish its lease on a network address by sending a 
message (RELEASE) to the server identifying the lease with its client 
identifier (hardware/network addresses). If the client used a client ID 
when it got the lease, it will use the same identifier in the message. 
Alternately, when a lease is near expiration, the client tries to renew it. If 
unsuccessful in renewing by a certain period, the client enters a rebinding 
state and sends a DISCOVER message to restart the process. 

DHCP also sets various options /extensions to clients which are outlined in 
"Assigned Network Configuration Values to Clients: Options" on page 299. 
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DHCP Services 

The DHCP services comprising the Bindings Database, leases, network 
options, and Client Class configuration are described below. 

Persistent Storage of Network Parameters for Clients 

The first DHCP service is persistent storage of network parameters for 
network clients, also known as the bindings database. The XSR directs the 
Server to store a [keyivalue] entry for each client, where the key is some unique 
identifier and the value contains configuration parameters for the client. 

For example, the key might be the IP -subnet-number /hardware-address pair. 
Alternately, the key might be the IP -subnet-number /hostname pair, allowing the 
server to assign parameters intelligently to a DHCP client that has been 
moved to a different subnet or has changed hardware addresses. DHCP 
defines the key to be IP -subnet-number /hardware-address unless the client 
explicitly supplies an identifier using the client identifier option. The XSR 
stores host IP and client-hardware addresses, intervals, client-identifiers, and 
client-names in the leases . cf g file. 

Temporary or Permanent Network Address Allocation 

The second DHCP service is temporary or permanent network (IP) address 
allocation to clients. Network addresses are dynamically allocated simply by 
a client requesting an address for an interval with the server guaranteeing not 
to reallocate that address within the requested time and attempting to return 
the same network address each time the client requests an address. 

Lease 

The period over which a network address is allocated to a client is called a 
lease. A client may extend its lease with follow-up requests and may issue a 
message to release the address back to the server when the address is no 
longer needed. Also, a client may request a permanent assignment by asking 
for an infinite lease. Even if it assigns permanent addresses, a server may 
distribute lengthy but non-infinite leases to allow detection of a retired client. 

In some environments network addresses must be reassigned due to the 
exhaustion of available addresses. In this case, the allocation mechanism will 
reuse addresses whose leases have expired. The server will use any available 
data in the configuration data repository to choose an address for reuse. 
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For example, the server may choose the least recently assigned address. As a 
consistency check, the allocating server will also probe the reused address 
before allocating the address - e.g., with an ICMP echo request - and the client 
will also probe the newly received address - e.g., with ARP. 

Assigned Network Configuration Values to Clients: Options 

With the exception of IP address assignment to clients, the DHCP Server 
provides a framework for passing configuration data to hosts on a TCP/IP 
network. Configuration values and other control data are carried in tagged 
data items which are stored in the options field of the DHCP message. The 
data items themselves, also called options, are enabled on the XSR by the 
options command specifying IP address, hex or ASCII string values. 
Supported options are defined in the "Dynamic Host Configuration Protocol 
Commands" chapter of the XSR CLI Reference Guide. 

RFC-1122 specifies default values for most IP/TCP configuration parameters. 
Provisioning Differentiated Network Values by Client Class 

One DHCP option - supported on the XSR by the client-class command - 
groups clients into classes with differentiated configuration. A DHCP Server 
selects appropriate parameters for the clients belonging to this class. For 
example, a Client Class can configure all enterprise users in Accounting with 
a different lease time than users in Marketing. 

RFC-3004 defines the User Class (Client Class) option for DHCP. 

BOOTP Legacy Support 

The XSR provides backward compatibility with BOOTP clients. When 
configured with a manual binding, it supplies a specified IP address to the 
client as well as a TFTP server IP address and file name to download (with the 
next -server command). 

Refer to "BOOTP Client Support Example " on page 308 for more information. 
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Nested Scopes: IP Pool Subsets 

As mentioned earlier, one of the main functions of the DHCP Server is to 
allocate IP addresses to clients. In that process, the DHCP Server works with 
three scopes or resource sets responsible for aggregated DHCP attributes - 
Pools or subnets, Client Classes, and Hosts. Scopes can be assigned other 
attributes as well as IP addresses, and can nest these attributes hierarchically 
much like files are organized in a directory tree. How these scopes interrelate 
can be loosely illustrated as shown in Figure 52. 



Pool (subnet) 

192.168.57.0 



\ Values are inherited 
\from outer scopes 

Client Class 



Elite 



X 



Values are inherited 
from outer scopes 



A nested scope may 
override an outer 
scope attribute 



X 

Host 

lcurtis-xp 



Attributes persist 
at the Host level 



Figure 52 DHCP Nested Scopes 



The Pool scope in Figure 52 defines and manipulates IP addresses and 
parameters. The Client Class scope manages sets of clients requesting DHCP 
Server services. The Host scope controls DHCP user parameters. 

When the DHCP Server surveys its clients by using the manual bindings of a 
client-identifier or hardware-address, and host address, it generally inherits 
attributes from an outer scope down to an inner scope. But, the DHCP Server 
will override outermost attributes when they are found first at the Host scope. 

For instance, if a domain -name is specified for lcurtis-xp in the Host scope and 
another domain-name in the Pool scope for all clients on the 192.168.57.0 
network, the DHCP Server will always select the Host scope attribute. 
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Scope Caveat 

Keep the following caveat in mind when configuring scopes: IP address pools 
may not be configured to overlap. The following conditions apply: 

- IP local pools may have multiple DHCP Servers per subnet for 
redundancy 

- Each DHCP Server should have a unique address pool that does 
not overlap pools on other DHCP servers 

For example, a correct IP range would be configured as follows: 

On subnet 90.1.1.0/24, the DHCP Server A range can be from 90.1.1.1 to 
90.1.1.150, and the DHCP Server B range can be from 90.1.1.151 to 90.1.1.254 

Manual Bindings 

An address binding is a mapping between the IP address and MAC address 
or Client-ID of a client. You can manually assign the IP address of a client or 
have it assigned automatically from a pool by a DHCP Server. 

Manual bindings are IP addresses that have been manually mapped to the 
MAC addresses of hosts recorded in the DHCP database. An unlimited 
number of manual bindings are stored in the startup-config file. 

Automatic bindings are IP addresses that have been automatically mapped to 
the MAC addresses of hosts recorded in the DHCP database. Automatic 
bindings are saved in persistent storage in the leases . cf g file. 

Manual bindings are set up by first creating a host pool, then specifying the IP 
address of the client and hardware-address or client-identifier. The hardware 
address is the MAC address. The client identifier, which is required for 
Microsoft clients (instead of a hardware address), is formed by concatenating 
the media type and the MAC address of the client. To configure manual 
bindings, perform the following steps: 

1 Enter ip dhcp pool <name> to create a name for the a DHCP Server 
address pool and acquire DHCP pool configuration mode. 
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2 Enter host address [mask | prefix-length] to specify the IP address 
and subnet mask of the client. 

The prefix length sets the number of bits that comprise the address 
prefix. The prefix is an alternative to specifying the network mask of 
the client. The prefix length must be preceded by a forward slash (/). 

3 Perform one of the following actions: 

- Specify a hardware address for the client. Enter: 

hardware -address <hardware-address> <type> client- 
class <name> 

or 

Specify the distinct identification of the client in dotted 
hexadecimal notation; e.g., 01b7.0813.8811.66, where 01 
represents the Ethernet media type. Enter: 

client-identifier <unique-identif ier> client-class 
<name> 

^ NOTE 

Manual bindings can be added by performing steps 2 and 3 in any order. 
But, when deleting a binding, enter the no form or the command (host, 
hardware -address or client-identifier) entered/z'rsf when created. 



4 Optionally, specify the client name using any standard ASCII 
character. Enter client-name <name>. 

The client name should not include the domain name. For example, 
the name acme should not be specified as acme.enterasys.com. 

DHCP CLI Commands 

The XSR offers CLI commands to provide the following functionality: 

□ DHCP Server address pool(s) with related parameters and DHCP 
options /vendor extensions. You can configure a DHCP address pool 
with a name that is a symbolic string (e.g., Accounting) with ip dhcp 
pool. Configuring a DHCP address pool also places you in DHCP 
pool mode - (config- dhcp -pool) # - from which you can configure 
pool parameters. The XSR supports adding 1000 network addresses 
per pool and one DHCP pool per network. 
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□ Create manual bindings of IP addresses and client hardware 
addresses - Manual bindings are comprised of: 

- host - the DHCP client's IP address and subnet mask or prefix 
length, entered with host 

hardware-address - the DHCP client's MAC address and platform 
protocol, entered with hardware -address, or 

- client-identifier - the DHCP client's unique marker is its combined 
media type and MAC address, entered with client- identifier. 

□ Delete client bindings from the DHCP Server, clear ip dhcp 
binding removes an automatic address binding from the DHCP 
database; no host, no hardware -address or no client-id 
remove manual bindings depending on which command was entered 
first when the binding was created. 

□ DHCP Server boot file(s) - The boot file is used to store a boot image 
for the client. The boot image is often the operating system a client 
uses to load. It is configured with bootf ile. 

□ Enable BOOTP Relay by configuring a destination address for UDP 
broadcasts with ip helper-address. 

□ Set domain name and DNS server - To put a client in the general group 
of networks comprising the domain, use domain -name. To specify the 
DNS server clients query when they need to correlate host names to IP 
addresses, use dns- server. 

□ Specify the NetBIOS server and node type for Microsoft clients - 
DHCP clients query DNS servers when they must resolve host names 
to IP addresses; enter an IP address of the NetBIOS MS WINS server 
using netbios -name- server. The XSR supports four node types of 
DHCP clients: broadcast, peer-to-peer, mixed, and hybrid. They can 
be specified using netbios -node- type. 

□ Configure a default router for the client - After a DHCP client has 
booted, the client begins sending packets to its default router. The IP 
address of the default router is required and should be on the same 
subnet as the client. Set using default -router. 

□ Configure the address lease time - IP addresses assigned by a DHCP 
Server have a one-day lease - the interval during which the address is 
valid. Specify with lease. 

□ Set the number of ping packets and ping wait interval - the DHCP Server 
pings an IP address twice before assigning a particular address to a 
requesting client. If the ping is unanswered, the server assumes (with a 
high probability) that the address is not in use and assigns the address to 
the requesting client. Use ip dhcp ping packets to change the 
number of ping packets the server should send to the IP address before 
assigning the address. 
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□ Use ip dhcp ping timeout to specify the period the server must wait 
before timing out a ping request. 

□ Monitor and maintain DHCP Server services by issuing the following 
show commands. Show ip dhcp bindings displays bindings data on 
the DHCP Server including lease expiration dates. Show ip dhcp 
conflict displays address conflicts found by a DHCP Server when 
addresses are offered to the client. Show ip dhcp server 
statistics is a useful catch-all command. Show ip local pool 
shows a list of active IP local pools, excluded and in use IP addresses. 



The DHCP Server is configured by performing the following: 

□ Allocate one or more address pools for DHCP clients. These pools can 
specify addresses on the local subnets of the router or external 
subnets whose clients reach the DHCP Server using BOOTP Relay. 

□ Exclude any addresses from these pools which must restricted and 
map to the DHCP pool. 

□ For each pool, define the set of DHCP network configuration 
parameters to be supplied to clients. 

□ Add manual (static) bindings to the DHCP pool configuration. 

□ Enable the DHCP Server on a FastEthernet interface only. 

Configuring DHCP - Network Configuration Parameters 

The DHCP Server can supply network configuration parameters; e.g., the IP 
address of the DNS Server to its clients. 

A DHCP client may require a large set of configuration parameters. Likewise, 
a network may contain a variety of different client types, each needing a 
different (possibly unique) set of network parameters. 

The XSR's DHCP setup is minimized for elaborate configuration by the use of 

scopes. 



DHCP Set Up 



Overview 



Configuring DHCP Address Pools 
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Configuration Steps 

Only four steps are required to minimally configure DHCP. They are: 

□ Create an IP Local Client Pool 

□ Create a Corresponding DHCP Pool 

□ Configure DHCP Network Parameters 

□ Enable the DHCP Server 
Optionally, you can also: 

□ Set up a DHCP Nested Scope 

□ Configure a DHCP Manual Binding 
These steps are described in the following sections. 

Create an IP Local Client Pool 

Begin DHCP configuration by specifying a pool of IP addresses for clients on 
a local or remote subnet (set via BOOTP Relay Agent). For this example, the 
local interface is assigned IP address 1.1.1.2 255.255.255.0. 

1 Add global pool local_clients including the starting IP address of the 
range and addresses that are unreachable to network clients: 

XSR (conf ig) #ip local pool localclients 1.1.1.0/24 
XSR(ip-local-pool) #exclude 1.1.1.249 6 

Create a Corresponding DHCP Pool 

2 Map this local pool to a DHCP pool by specifying the correct name: 

XSR (conf ig) #ip dhcp pool localclients 

Configure DHCP Network Parameters 

3 On the pool just supplied to DHCP, define some attributes for network 
clients. They include the lease duration (dynamic leases) of two hours 
and 30 minutes, IP addresses of the default router and DNS server 
(these IP addresses derive from the excluded address range on the 
IP local pool), and the Enterasys.com domain name. 

XSR (conf ig-dhcp-pool) #lease 0 2 30 

XSR (conf ig- dhcp -pool ) #default- router 1.1.1.249 1.1.1.250 
XSR (conf ig-dhcp-pool) #dns-server 1.1.1.254 
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XSR (conf ig-dhcp-pool) #domain-name ets . enterasys . com 

^ NOTE 

Some values can also be configured for a Client-Class or Host scope. 



Enable the DHCP Server 

4 Initialize the DHCP Server on FastEthernet interface 2: 

XSR (conf ig) #interf ace fastethernet 2 
XSR (conf ig-if<F2>#ip dhcp server 

Optional: Set Up a DHCP Nested Scope 

5 Continue configuring local_clients by creating a named client-class 
and using it to override the lease time. Clients presenting this name in 
DHCP messages will get the shorter lease time but will continue to 
receive dns-server and other values defined in the pool. 

XSR (conf ig) #ip dhcp pool localclients 
XSR (conf ig-dhcp-pool) #client-class classl 
XSR (conf ig-dhcp-class) #lease 0 0 30 

6 Extend the client-class attributes to include the address of a 
NetBIOS-name-server: 

XSR (conf ig-dhcp-class) #netbios -name-server 1.1.1 .253 

Optional: Configure a DHCP Manual Binding 

7 Add a manual binding in the local_client pool: 

XSR (conf ig-dhcp-class) #host 1.1.1.7 255.255.255.0 
XSR (conf ig-dhcp-host) #hardware- address 1111.2222.3333 1 

8 Add to the host scope by specifying the NetBIOS-node-type for this 
particular host: 

XSR (conf ig-dhcp-host) #netbios -node- type h-node 

9 Specify any numbered options. For example, setting DHCP option 28 
specifies the broadcast address in use on the client's subnet: 

XSR (conf ig) #ip dhcp pool localclients 

XSR (conf ig-dhcp-pool) #option 28 ip 255.255.255.255 
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DHCP Server Configuration Examples 

The following examples configure DHCP with different options. For DHCP 
implementations with firewall configured, refer to "Configuring Security on 
the XSR" on page 311. 

Pool with Hybrid Servers Example 

In the following example, the single DHCP pool dpool is created and two 
default routers defined: 168.16.22.100 (higher preference) and 168.16.22.101 
(lower preference). The domain name enterasys.com is specified and a list of 
two DNS servers defined - 168.16.33.102 (higher) and 168.16.33.103 (lower). 
NetBIOS servers are specified as type hybrid - 168.16.44.103 (higher) and 
168.16.44.104 (lower). Finally, the lease time for all clients is limited to 10 days. 

XSR(conf ig) #ip local pool dpool 168.16.22.0/24 
XSR (conf ig) #ip dhcp pool dpool 

XSR (conf ig-dhcp-pool) #default- router 168 . 16 . 22 . 100 168 . 16 .22 .101 

XSR (conf ig-dhcp-pool) #domain-name enterasys . com 

XSR (conf ig-dhcp-pool) #dns-server 168.16.33.102 168.16.33.103 

XSR (conf ig-dhcp-pool) #netbios -name- server 168 . 16 .44 . 103 168 . 16 .44 . 104 

XSR (conf ig-dhcp-pool) #netbios -node- type h-node 

XSR (conf ig-dhcp-pool) #lease 10 

Manual Binding Example 

In the following example, the single DHCP pool dpool is created with a 
domain name enterasys.com. A host is defined with MAC address 
00:f0:12:ll:22:al in dotted decimal format and a manual binding is specified 
by IP address 1.1.1.20 and mask 255.255.255.0. 

The domain name for this host is specified as ent.com (this will override 
enterasys.com specified for this pool). 

XSR (conf ig) #ip local pool dpool 1.1.1.0/24 
XSR (conf ig) #ip dhcp pool dpool 

XSR (conf ig-dhcp-pool) #domain-name enterasys . com 
XSR (conf ig-dhcp-pool) #hardware- address OOf 0 . 1211 . 22al 
XSR (conf ig-dhcp-host) #host 1.1.1.20 255.255.255.0 
XSR (conf ig-dhcp-host) #domain-name ent . com 
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Manual Binding with Class Example 

In the following example, the single DHCP pool dpool is created with the 
domain name enterasys.com. A class engineering is defined. The domain name 
for all hosts is ent.com. A host is defined with a MAC address in dotted 
decimal format. A manual binding is specified by IP address 1.1.1.20 and 
mask 255.255.255.0. 

The domain name for this host is specified as indusriver.com (this will override 
enterasys.com specified for this pool, and ent.com specified for the class). 

XSR (conf ig) #ip local pool dpool 1.1.1.0/24 
XSR (conf ig) #ip dhcp pool dpool 

XSR (conf ig-dhcp-pool) #domain-name enterasys . com 

XSR (conf ig-dhcp-pool) #client-class engineering 

XSR (conf ig-dhcp-class) #domain-name ent . com 

XSR (conf ig-dhcp-class) #hardware- address OOf 0 . 1211 .22al 

XSR (conf ig-dhcp-host) #host 1.1.1.20 255.255.255.0 

XSR (conf ig-dhcp-host) #domain-name indusriver.com 

BOOTP Client Support Example 

In the following example, the XSR is configured to support a BOOTP client to 
download an image file from a TFTP server. Configured within the DHCP 
pool BOOTP download, the client is assigned a manual binding of host IP and 
hardware addresses (or optionally, its client-id), the TFTP server's IP address, 
and the name of the file to be downloaded, acme. hex. Also, a static ARP entry 
is configured. 

XSR (conf ig) #ip dhcp pool BOOTPdownload 

XSR (conf ig-dhcp-pool) #host 192.168.1.33 255.255.255.0 

XSR (conf ig-dhcp-pool) #next-server 192 .168.1.234 

XSR (conf ig-dhcp-pool) #bootf ile acme .hex 

XSR (conf ig-dhcp-pool) #hardware- address 0000 . ldll .e829 

XSR (conf ig)#arp 192.168.1.33 0000 . 1D11 . E82 9 

When the MAC address 0000. ldll. e829 (BOOTP client) transmits a BOOTP 
request, the DHCP server will respond with the IP address 192.168.1.33, the 
boot file name acme.hex and the next-server IP address 192.168.1.234. 



308 



XSR User's Guide 



Chapter 12 
Configuring DHCP 



DHCP Server Configuration Examples 



DHCP Option Examples 

The following sample DHCP option configurations illustrate the three types 
of option parameters prompted for by the CLI: IP address, ASCII and hex. For 
more examples, refer to the XSR User's Manual. 

The following example configures DHCP option 3, which lists the IP 
addresses of four default routers on the DHCP client's subnet in descending 
order of preference. This setting can also be configured by the DHCP 
default -router command. Be sure to first exclude these addresses from the 
IP local pool to prevent them from being allocated by the DHCP server. 

XSR(conf ig-dhcp-pool) #option 3 ip 192.168.57.90 192.168.57.26 
192.168.57.54 192.168.57.78 

The following example configures DHCP option 12, which specifies the host 
name of a client which may or may not be qualified with the local domain 
name. The option parameter is expressed in ASCII text but can also be 
configured by the DHCP client -name command. The name should not 
include the domain name. 

XSR (conf ig-dhcp-host) #option 12 ascii jonah 

The following example configures DHCP option 29, which specifies that the 
the client will perform subnet mask discovery using ICMP 

XSR (conf ig-dhcp-host) #option 29 hex 01 
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This chapter describes the security options available on the XSR including the 
firewall feature set and methods to protect against hacker attacks. 

Features 

The following security features are supported on the XSR: 

□ Standard and Extended Access Control Lists (ACL) 

□ Protection against LANd attack: Destination IP equals Source IP 

□ Protection against ICMP echo to directed subnet 

□ Protection against UDP echo request to directed subnet broadcast 

□ IP packet with multicast/broadcast source address 

□ Spoofed address checking 

□ SYN flood, FIN attack mitigation 

□ TCP server resource release 

□ ICMP traffic filtering based on IP data length, IP offset, IP 
fragmentation bits including: 

- Fragmented ICMP traffic 
Large ICMP packets 
Ping of Death attack 

□ Filter TCP traffic with SYN, and FIN bits set 

□ AAA services 

□ Firewall feature set 



NOTE 



Activating any of the above features will affect system performance. 
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Access Control Lists 

Access Control Lists (ACL) impose selection criteria for specific types of 
packets, which when used in conjunction with other functions can restrict 
Layer 3 traffic through the XSR. They are configured as follows: 

□ Standard access lists (1-99) restrict traffic based on source IP addresses 

□ Extended access lists (100-199) filter traffic from source and destination 
IP addresses, protocol type (ICMP, TCP, UDP, GRE, ESP, AH), port 
number ((TCP, UDP), and type/code (ICMP) 

To configure ACLs, you define them by number only then apply them to an 
interface. Any number of entries can be defined in a single ACL and may 
actually conflict, but they are analyzed in the order in which they appear in 
the show access -lists command. 

Input and output filters are applied separately and an interface can have only 
one ACL applied to its input side, and one to its output side. Also, the ACL 
netmask is complemented. For example, 0.0.0.255 indicates that the least 
significant byte is ignored. 

The XSR implementation of ACLs is limited by the following conditions: 

□ The total number of ACL entries allowed is 500 

□ For crypto maps and ACLs applied to the same interface, the XSR 
gives precedence to the crypto map, which is always consulted before 
the ACL on a port for both inbound and outbound traffic. If IPSec 
encrypts or decrypts packets due to the crypto map configuration 
then the ACL is ignored. 

Packet Filtering 

Packet filtering is configured via standard and extended access -list 
commands. For more information, refer to the XSR CLI Reference Guide. 

LANd Attack 

Protection against LANd attacks is triggered when a packet arrives with the 
IP source address equal to the IP destination address. This is an illegal IP 
packet and it is discarded by the XSR when the protection is enabled with the 
Ho st Dos command. See the Firewall section for more details. 
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Smurf Attack 

A " smurf ' attack involves an attacker sending ICMP echo requests from a 
falsified source (a spoofed address) to a directed broadcast address, causing 
all hosts on the target subnet to reply to the falsified source. By sending a 
continuous stream of such requests, the attacker can create a much larger 
stream of replies, inundating the host whose address is being falsified. 

The XSR protects against smurf attacks by turning off directed broadcast and 
turning on checkspoofing. Refer to "Configuring IP" on page 63 and the XSR 
CLI Reference Guide for more information on IP directed broadcast. 

Fraggle Attack 

A "fraggle" attack involves a UDP Echo-directed broadcast. It is similar to a 
smurf attack but differs in that it uses UDP instead of ICMP packets. 

The XSR protects against a fraggle attack by turning off directed broadcast 
and turning on checkspoofing. Refer to "Configuring IP" on page 63. 

IP Packet with Multicast/Broadcast Source Address 

This type of attack involves an illegal IP packet. Because XSR interfaces are 
programmed to discard these packets, no user configuration is necessary. 

Spoofed Address Check 

This feature allows spoofing of IP source addresses by checking the source 
address of a packet against the routing table to ensure the return path of the 
packet is through the interface it was received on. 

SYN Flood Attack Mitigation 

Also known as a Denial of Service (DoS) attack, this involves a hacker 
flooding a server with a barrage of requests for access to unreachable return 
addresses. Since the return addresses are unreachable, the connections cannot 
be built and the ensuing volume of unresolved open connections eventually 
overwhelms the server, causing service denial to valid requests. A SYN flood 
attack against the XSR is defended by the router not checking transit packets. 
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This feature is always enabled, and the maximum number of TCP sessions 
allowed is set at run time, depending on the number of TCP applications 
running, and the maximum number of sessions each of them could have. Any 
connection attempt above this number is denied. 

Fragmented and Large ICMP Packets 

The XSR offers these features to filter ICMP traffic based on IP data length, IP 
offset, and IP fragmentation bits. They apply to packets destined for the XSR. 
Transit packets will not be checked. 

Fragmented ICMP Traffic 

This protection is triggered for ICMP packets with the "more fragments" flag 
set to 1, or an offset indicated in the offset field. Such packets are dropped by 
the XSR if the protection is enabled with the HostDoS command. 

Large ICMP Packets 

This protection is triggered for ICMP packets larger than a size you can 
configure. Such packets are dropped by the XSR if the protection is enabled 
with the HostDoS command. 

Ping of Death Attack 

This protection is triggered when an ICMP packet is received with the "more 
fragments" bit set to 0, and ((IP offset * 8) + IP data length) greater than 65535. 
As the maximum size for an IP datagram is 65535, this could cause a buffer 
overflow. Such packets are always dropped automatically by the XSR. 

Spurious State Transition 

Protection against spurious state transition concerns TCP packets with Syn 
and Fin bits set. This type of attack occurs when an intruder attempts to stall a 
network port for a very long time, using the state transition from state 
SYN_RCVD to CLOSE_WAIT, by sending a packet with both SYN and FIN 
flags set to a host. 

The host first processes the SYN flag, generates the ACK packet back, and 
changes its state to SYN_RCVD. Then it processes the FIN flag, performs a 
transition to CLOSE_WAIT, and sends the ACK packet back. 
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The attacker does not send any other packet, and the state machine of the host 
remains in CLOSE_WAIT state until the keep-alive timer resets it to the 
CLOSED state. To protect against this attack the XSR checks for TCP packets 
with both SYN and FIN flags set. With protection always enabled, these 
packets are harmlessly dropped. 

This feature is supported for packets destined for the XSR. Transit packets 
will be checked. 

General Security Precautions 

To ensure security on the XSR, we recommend you take these precautions: 

□ Limit physical access 

□ Avoid connecting a modem to the console port 

□ Download the latest security patches 

□ Retain secured backup copies of device configurations 

□ Plan all configuration changes and prepare a back-out procedure if 
they go wrong 

□ Keep track of all configuration changes made to all devices 

□ Create a database that tracks the OS version, description of last 
change, back-out procedure, and administrative owner of all routers 

□ Avoid entering clear text passwords in the configuration script 

□ Be sure to change all default passwords 

□ Use strong passwords not found in the dictionary 

□ Change passwords when the IT staff departs 

□ Age passwords after 30 to 60 days 

□ Grant the correct privilege levels to particular users only 

□ Set reasonable timeouts for console and remote management sessions 

□ If you must enable PPP on the WAN, use CHAP authentication 

□ Disable all unnecessary router services (e.g., HTTP, if not used) 

□ Write strict ACLs to limit HTTP, Telnet and SNMP access 

□ Write ACLs to limit the type of ICMP messages 
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□ Create ACLs to direct services to appropriate servers only 

□ Enable packet filtering and attack prevention mechanisms 

□ All only packets with valid source addresses to exit the network 

□ If using SNMP, use strong community names and set read-only access 

□ Minimize console logging to limit unnecessary CPU cycles 

□ Use OSPF rather than RIP to take advantage of MD5 authentication 

□ Control which router interfaces can be used to manage the XSR 

□ Use an SNTP server on the DMZ to synchronize XSR clocks 

□ Use syslog to send messages to a designated syslog server 

AAA Services 

The XSR provides Authentication, Authorization and Accounting (AAA) 
services to validate and display data for AAA usergroups, users, and methods. 
For Telnet/ Console and SSH users, two authentication mechanisms are 
available, as follows: 

□ CLI database authentication - This is the authentication mode used for 
Telnet/ Console and SSH users by default. Users are authenticated 
against the CLI database created by the username command. This 
mechanism does not provide for RADIUS authentication. 

□ AAA user database authentication - This mechanism allows 
Telnet/ Console and SSH users to use the AAA module which 
provides further authentication by various AAA methods including 
RADIUS. The aaa client telnet command switches all 
Telnet/ Console users to authenticate via the AAA user database. The 
aaa client ssh command switches all SSH users to authenticate via 
the AAA user database. 

A few restrictions apply when switching Telnet /Console and SSH users to 
authenticate via this mechanism, as follows: 

□ No pre-existing privilege-15 admin user exists in the AAA database. 

□ Before switching over to AAA for Telnet or SSH, at least one privilege 
15 user with a Telnet/SSH policy must exist in the AAA database. 
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□ Deleting the only privilege-15 user with Telnet or SSH policy is 
disallowed to prevent any accidental loss of access to the XSR. 

There are two types of default AAA methods, as follows: 

□ The default AAA method for the AAA service. This is set using the 
aaa method [local | pki | radius] default command. By 
default, the local method is the default AAA method for the AAA 
service. 

□ The default AAA method for individual clients such as VPN, SSH, 
Firewall, and Telnet. This is set on a per client basis via the client 
{telnet | ssh | firewall | vpn } sub-command under the aaa 
method command. 

If the latter default is not specified for a client, the former default applies. 

The method for performing AAA is configured with the top-level aaa method 
command, which is sub-divided into acct-port, address, attempts, auth- 
port, backup, client, enable, group, hash enable, key, qtimeout, 
retransmit, and timeout sub-commands. The default method for AAA 
service is set to local by default. But if you wish, you can authenticate to a 
RADIUS server or PKI database. Most of the AAA method sub-commands 
are available for RADIUS service only (refer to "Firewall Configuration for 
RADIUS Authentication and Accounting" on page 352 for details). 

The AAA method sub-command client sets the default AAA method for any 
of these client services: VPN, Telnet, Firewall or SSH. If you do not invoke this 
command, the AAA service's default method (set by aaa method [ local | 
pki | radius] default) will apply. For example, if the default method has 
not been set for Telnet using the client telnet sub-command under aaa 
method, then the default method for AAA service will be used. 

Additional AAA method sub-commands acct-port and auth-port set 
UDP ports for accounting and authentication requests, respectively. 

AAA users can be added to AAA service with the top-level aaa user 
command, which is sub-divided into group, ip address, password, 
privilege, and policy sub-commands which set those users' respective 
attributes. 
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While most of these parameters are self-explanatory, the policy value is 
important in specifying which system each user will be allowed to access on 
the XSR. The module options are: firewall, ssh, telnet, and vpn.. Their 
intended functions are, as follows: 

□ Telnet/Console: administrators and low-level Console users who will 
use the standard serial connection application 

□ SSH: users who will require a more secure Telnet-type connection 

□ Firewall: users who will access the firewall 

□ VPN: users who will tunnel in to the XSR 

AAA users can be assigned to groups with the aaa group top-level 
command, which is sub-divided into dns and wins server, ip pool, 12 tp 
and pptp compression, pptp encrypt mppe, privilege, and policy sub- 
commands to set that group's respective parameters. Any users not 
specifically assigned to a group are added to the default AAA group. 
Policies can be set at both the user and group level but a user-level policy 
overrides a user's group-level policy. 

Although AAA authentication is set by the service not the user, you can 
override this rule by configuring a user with the @ (username@sbr.com). The 
XSR checks if the ©-configured user is configured before enabling the default 
authentication service. 

Refer to the following section to configure SSH or Telnet with AAA 
authentication. 

Connecting Remotely via SSH or Telnet with AAA Service 

Perform the following commands to configure SSH or Telnet service: 

1 Enter configure to acquire Configuration mode. 

2 Enter crypto key master generate to create a master key. 

3 Enter crypto key dsa generate to create a host key pair on the XSR. 

When successful, this message will display: Keys are generated, 
new connetions will use these keys for authentication 

4 If you wish to connect using SSH, perform the following steps, 
otherwise skip to Step 15 for Telnet configuration. 
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Install a freeware program such as PuTTY on your client device. If 
you load PuTTY, enable these options for maximum ease of use: 

Click Session, Close window on exit, Never. See Figure 53. 

Click Terminal, Local echo, Force off. 

Click Terminal, local line editing, Force off. 

Click Connection, SSH, Don 't allocate a pseudo-terminal. 



2^ PuTTY Configuration 



Category: 



□■■ Session 

Logging 
■ Terminal 
Keyboard 
Bell 

Features 
Window 

Appearance 
Behaviour 
Translation 
Selection 
Colours 
B Connection 
Proxy 
Telnet 
R login 
SSH 
Auth 
■■■■ Tunnels 
Bugs 



About 



Basic options for your PuTTY session 
Specify your connection by host name or IP address 
Host Name [or IP address) Port 



23 



Protocol: 



©lelnet ©Rlogin ©SSH 



Load, save or delete a stored session 
Saved Sessions 



Default Settings 



Load 



Save 



Delete 



Close window on exit: 

O Always © Never : y j Only on clean exit 



□ pen 



Cancel 



Figure 53 PuTTY Exit Option 



6 Enter session-timeout ssh <15-35000> to set the idle timeout 
period. 

7 Optionally, if you want to tighten security on the XSR, enter ip telnet 
server disable to deactivateTelnet. 
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8 Enter aaa user <name> to create an authenticated user and acquire 
AAA user mode. 

9 Enter password <your password> for the newly created user. 

10 Enter privilege 15 to set the highest privilege level for the user. 

11 Enter policy ssh to enable SSH access for the user. 

12 Enter exit to quit AAA user mode. 

13 Enter aaa client ssh to enable AAA client SSH user authentication. 
If you also want to enable Telnet, enter aaa client telnet. The XSR is 
now ready to connect the remote login user. 

14 Perform Steps 7-10. 

15 Enter session-timeout telnet <15-35000> to set the idle timeout 
period. 

16 Optionally, if you want to tighten security on the XSR, enter ip ssh 
server disable to deactivate SSH. 

17 Enter policy telnet to enable Telnet access for the new user. 

18 Enter exit to quit AAA user mode. 

19 Enter aaa client telnet to permit the new user to employ Telnet. 

The XSR is now ready to connect remote login users. 

Remember to save your configuration after all edits. 
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Firewall Feature Set Overview 

A firewall is defined generally as a set of related applications or a device 
dedicated to protect the enterprise network. Placed at any entryway to a 
corporation's private network, a firewall examines all packets arriving from 
the Internet and admits or bars traffic based upon its policies. A firewall may 
also control inside access to destinations on the Internet or interior resources. 

Fundamentally, a firewall monitors and filters network traffic. Depending on 
your enterprise needs, you can set up a simple or more robust firewall. For 
instance, application-level filtering can be matched to source/ destination IP 
addresses and port numbers for FTP, HTTP, or Telnet; protocol-level filtering 
can be set on IP protocols such as OSPF, IGP or ICMP; and stateful filtering can 
be applied to a session's state. 

Reasons for Installing a Firewall 

The rationale for installing a firewall can include the following: 

□ Provide a focal point for security decisions 

□ Segment networks into discrete security zones 

□ Enforce security policy between different security zones to protect 
proprietary information from falling into the wrong hands 

□ Enable users to safely connect to and conduct business over a public, 
untrusted network (Internet): 

Restrict undesirable traffic that may otherwise flow between 
your internal hosts and the Internet 
- Protect internal networks from hostile and malicious attacks 

□ Log network activity 

□ Limit your exposure in case of a successful attack 

Ideally, these network nodes should be checked daily for security holes, but 
since that is impractical, the next best course is to run a firewall to block all 
non-essential ports and cut the risk of attack. A firewall can be conceived as a 
virtual wall through which "holes" or ports are opened to allow permitted 
traffic through as shown in Figure 54 which illustrates a topology using the 
XSR firewall feature set. 
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There are many possible network configurations for a firewall. The figure 
above shows a scenario with the firewall connected to the trusted network 
(internal) and servers that can be accessed externally (via the DMZ). 

The XSR firewall feature set inspects packets coming in from open ports and 
either passes them on to the router or drops them based on policies defined in 
the policy database which is configured using the XSR's CLI. 

In this example, the firewall acts as a shield for traffic coming in and out of the 
external and DMZ networks. The internal interface does not have nor does it 
need firewall inspection enabled because it is a trusted network. 
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While this flexibility is useful, it emphasizes the fact that the shield is only as 
effective as the intelligence of the policies. Functionally, the XSR's policy 
database defines the configuration and retains information about the sessions 
currently allowed through the firewall. 

Types of Firewalls 

Generally speaking, there are three types of firewalls: Access Control List 
(ACL) or Packet Filter, Application Level Gateway (ALG) or Proxy, and 
Stateful Inspection. Each of these firewall types operate at different layers of 
the TCP/IP network model, using different criteria to restrict traffic. 

ACL and Packet Filter Firewalls 

ACL and packet filter firewalls statically apply security policy to a packet's 
contents according to pre-configured rules you specify such as permitted or 
denied source and destination addresses and port numbers. These firewalls 
are scalable, easy to implement and widely deployed for simple Network 
layer filtering, but they suffer the following disadvantages: 

□ Do not maintain states for an individual session nor track a session 
establishment protocol. Ports are usually always open or blocked 

□ Do not examine application data 

□ Do not work well with applications which open secondary data 
channels using embedded port information in the protocol - "difficult 
protocols" such as FTP and H.323 (video conferencing applications) 

□ Cannot detect protocol-level problems and attacks 

□ Less secure than stateful inspection or proxy firewalls 

ALG and Proxy Firewalls 

ALG or proxy firewalls filter packets at the top of the stack - Layer 5. They: 

□ Act as an agent (proxy) between IP client and server transactions. A 
proxy server often runs on dedicated, hardened operating systems 
with limited functionality, offering less of a chance to be 
compromised 
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□ Filter bad packets and bad contents to protect internal hosts incapable 
of protecting themselves against these attacks: 

- Bad packets (too long or too short) 

- Un-recognized commands (possible attack) 

- Legal but undesirable commands/ operations (as set by policy) 

- Objectionable contents (content and URL filtering) 

□ Drop incoming/ outgoing connections such as FTP, gopher, or Telnet 
applications at the proxy firewall first 

□ Create two connections, one from the client to the firewall, the other 
from the firewall to the actual server. This generates a completely 
new packet which is sent to the actual server based on its data "read" 
of the incoming packet and correct implementation of the 
application's protocol. When the server replies, the proxy firewall 
again interprets and regenerates a new packet to send to the client. 

□ Build another layer of protection between interior hosts and the 
external world forcing a hacker to first break into the proxy server in 
order to launch attack on internal hosts 

But the above advantages of an application or proxy firewall are offset by the 
following weaknesses: 

□ Higher overhead - because it is usually implemented at the Application 
layer, additional processing is needed to transfer packets between the 
kernel and the proxy application 

□ Non-scalability - support for a new protocol or a new feature of an 
existing protocol often lags by months or years 

□ Non-transparency - proxy server users may discover the server bars an 
application, forcing users to find alternatives 

Stateful Inspection Firewalls 

A stateful inspection firewall combines the aspects of other firewalls to filter 
packets at the network layer, determine whether session packets are 
legitimate and evaluate the payload of packets at the application layer. 

It allows a direct connection between client and host, alleviating the lack of 
transparency of ALGs. Also, it employs algorithms to recognize and process 
Layer 5 data rather than run application-specific proxies. 
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Additionally, a stateful inspection firewall provides: 

□ Inspection of a packet's communication and application state - 
acquired from past communication data throughout all layers. For 
example, an FTP session's PORT command can be saved to verify an 
incoming FTP data connection 

□ Dynamic filtering by opening ports only if the configured policy 
permits and when the application requires it 

□ The strongest security with the least processing overhead and fastest 
performance because stateful inspection is implemented in the kernel 

□ An Application Layer Gateway (ALG) to support applications which 
dynamically allocate ports for secondary data streams. ALGs apply 
stateful inspection to a difficult protocol such as FTP or H.323 by 
tracking control messages between client and server and learning the 
correct port number to open at the correct time. 

□ Smart service filtering and blocking. For example, it blocks un- 
authorized commands to an Email server, avoiding possible attacks 

□ More intelligent packet flooding attack prevention 

□ The capacity to search for and reject non-forming packets 

XSR Firewall Feature Set Functionality 

The XSR's firewall feature set provides the following functionality: 

Stateful Firewall Inspection (SFI) - Stateful inspection is provided for TCP and 
UDP packets and monitoring of all incoming and outgoing TCP/UDP sessions. 
Incoming sessions must be explicitly allowed by configuring policy rules. 

For TCP, sessions are created and deleted by monitoring TCP SYN/ ACK/FIN 
flags. Sessions for UDP are created based on packet flows with the first 
outbound UDP packet creating the session. Inactivity for an interval deletes 
the session. 

Stateful inspection is available for user-defined applications as well as those 
shown in Table 12. Enter the show ip firewall services command for 
associated source and destination port ranges and TCP/UDP affiliations. 
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Table 12 Pre-defined Services 



ANY_TCP 


ANY_UDP 


AOL 


a . .xi_ i i r*v i— * 

AuthUDP 


AudioCallCtrl 


Bootp 


Bootpc 


Bootp_relay 


DNSTCP 


DNSUDP 


Finger 


FTP 


H323 


HTTP 


1 A 1 ' i 

ICAChent 


ICABrowse 


IdentD 


I MAP 


IMAPS 


IRC 


i o a i/nn 

ISAKMP 


KerberosAdmTCP 


KerberosAdmUDP 


KerberosTCP 


KerberosUDP 


klogin 


L2TP 


LDAP 


Login 


LotusNotes 


Microsoft_ds 


MSN 


NetBIOS_ns 


NetBIOS_tcp 


NetBIOS_udp 


Nro 1 Or 


mcci i p\ n 
NroUUr 


NN 1 r 


N 1 r_UUr 


PCAnywhere 


P0P3 


P0P3S 


PPTP 


Radius 


Radius_ACCT 


RealAudio 


RealPlayer 


RealPlayerG2 


RealPlayerUDP 


Route 


SMB_TCP 


SMS 


SMTP 


SNMP 


SNMP_TRAP 


SSH 


SSL 


SysLog 


T120 


Telnet 


TermServ 


TFTP 


TimeUDP 


ULS 


Whols 


XDMCP 


X11 









Filtering non TCP/UDP packets - Non TCP and UDP IP packets are controlled 
by a separate filtering mechanism and configured with a filter object. All non 
TCP and UDP packets are dropped by default. In order to pass a particular IP 
protocol packet through the firewall, you must configure a filter object for 
that protocol with the correct source and destination addresses. 

Application level commands - A special action option - Command Level Security 
(CLS) - to filter inter-protocol actions within several protocols. The CLS 
examines the message type produced by the application being filtered and 
either passes or drops specific application commands. For example, FTP GETs 
can be allowed but PUTs denied. These protocols are supported: 

□ File Transfer Protocol (FTP) 

□ Simple Mail Transport Protocol (SMTP) 

□ Hypertext Transfer Protocol (HTTP) 
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Application Level Gateway - Support for FTP and H.323 version 2 protocols 

Denial of Service (DoS) attack protection - Security for internal hosts against a 
common set of DoS attacks when the firewall is enabled (globally and per 
interface). The firewall also uses the XSR's HostDoS feature to perform anti- 
spoofing - it enforces hostDos checkspoof for any firewall-enabled interface 
regardless of the hostDoS checkspoof setting. Checkspoofing is perfomred by 
validating the source IP address against the Routing table. If a packet is 
received from an interface with a source IP address that is not routable 
through this interface, it is considered spoofed and dropped. See the XSR CLI 
Reference Guide for more information. 

A high priority log is generated when DoS attacks are detected. The following 
DoS attacks are covered: 

□ Anti-Spoofing - In response to a spoof attack, the firewall drops all 
packets with a source address belonging to an internal network when 
received from an external interface. Packets from an internal interface 
with a source address not in the network will also be dropped. 

□ ICMP Flood - In response to ICMP echo requests that are received 
from different source addresses at a very high rate, the firewall sets a 
rate limit of ICMP echo requests processed per second. 

□ Ping of Death - In response, fragmented echo requests are dropped. 

□ Smurf attack - In response to a smurf attack where ICMP echo requests 
with the directed broadcast address is the destination and the source 
is any host, the firewall will filter echo requests to directed broadcasts 
or all directed broadcast packets. 

□ SYN Flood - In response to a continuous stream of TCP open packets 
(SYN bit set) targeting an address, the firewall will limit the number 
of half-open TCP connections and set a max rate of TCP links. 

□ Tear drop - In response to receiving IP fragments that overlap, the 
firewall will track fragments received for every session, detect bad 
offsets and drop the entire packet (all fragments). 

□ Christmas Tree - When a TCP packet is received with all flags set, TCP 
packets with any two of the SYN, FIN or RST bits set are dropped. 

□ LANd - In response to receiving a TCP SYNC packet with the same 
source and destination address, the firewall will drop any packet 
with same source and destination address. 
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Alarm Logging - The XSR supports Console and Syslog logging and provides 
session usage data using the allow-log / log options. If you want to enable 
persistent logging which preserves logs after a system reboot, you must install 
a CompactFlash memory card in the XSR. Logs stored in Flash are purged 
during a system reboot unless the XSR senses the presence of CompactFlash. 

Alarms - The XSR generates firewall alarms in the following categories: 

□ TCP and UDP packets 

- Permitted connect and disconnect 
Blocked connects and disconnects 
Blocked data packet 

- Individual packet logging per user configured firewall policy (by 
stipulating allow_log or log) 

□ IP option Permit or Deny logs 

□ Other Protocols Permit or Deny Logs 

- OSPF, ESP, RIP, GRE 

- ICMP 
Broadcast, multicast 

□ Specific FTP, HTTP and SMTP requests logs 

□ Flooding attacks (TCP, UDP, ICMP) logs 

□ Firewall start and restart 

□ Failures (out of memory) 

A sample Web access (port 80) permit alarm, which logs at level 4, displays: 

FW: Permit: Port-2, Out TCP Con_Req, 10.10.10.10(1042) -> 192.168.1.200(80) 

FW: TCP new session request. 10.10.10.10(1042) -> 192.168.1.200(80) 

FW: Permit: Port-1, TCP Con_Est, 192.168.1.200(80) -> 10.10.10.10(1042) 

FW: TCP connection closed 192.168.1.200(80) -> 10.10.10.10(1042) 

A sample client open connection to the FTP server (port 21) alarm displays: 

FW: Permit: Port-1, Out TCP Con_Req, 10.10.10.10(1056) -> 192.168.1.100(21) 
FW: TCP new session request. 10.10.10.10(1056) -> 192.168.1.100(21) 
FW: Permit: Port-1, TCP Con_Est, 192.168.1.100(21) -> 10.10.10.10(1056) 

The IP addresses cited in firewall alarms are selected as follows: 

- If a syslog server is configured, alarms will contain the XSR IP 
address that is used to contact the syslog server. 
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- If no syslog server is configured, alarms will contain the IP 
address of the first circuit. FE1 will be checked first, then FE2, 
then any WAN interface etc., until an IP address is obtained. 

- If no interfaces have been configured with an IP address, the 
hostname will be used. 

Authentication - AAA services provide secure access across the firewall 
delineated by several levels: user, client and session. This release supports only 
client authentication which verifies a remote host based on its IP address. All 
firewall policy rules that specify allow-auth as the action check the source IP 
address of the received packet in the auth cache before approving the session. 

For the remote user, the XSR requires manual sign-on using Telnet to the 
default port 3000 or another configured port. The user is prompted for a user 
name and password, and those credentials are checked with either an 
authentication server (RADIUS) or a local database on the XSR (see 
Figure 55). 




Figure 55 Authentication Process 



Figure 55 illustrates the process by which a user accesses a server after 
authentication by the XSR firewall, as explained below: 

1 A user Telnets to the firewall presenting a name and password. 
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2 The XSR's AAA functionality talks to an authentication server or 
consults a local database based on the user's credentials. 

3 If authentication is successful, AAA informs the firewall engine of the 
user's source IP address and an authentication entry is created within 
the firewall engine. 

4 Policy rules specified for the firewall allow the user access to a server 
after consultation with the firewall engine's authentication cache. 

Authentication failures are tracked using logs or traps and entries 
time out after an inactive period. If authentication fails, all packets 
that match policy rules with allow-auth for that source IP are dropped. 

Firewall and NAT - On outgoing packets, stateful inspection is done before NAT 
because NAT modifies the source address of all packets to that of the XSR and 
policy rules are defined with respect to internal and external addresses. On 
incoming packets, NAT is preformed before firewall inspection. 

Firewall and VPN - VPN tunnels are implemented as virtual interfaces that 
"sit" on physical interfaces. Stateful inspection is applied before encryption 
and encapsulation on outgoing packets and after de-capsulation and 
decryption on incoming packets. 

ACLs and Firewall - Access Control Lists are available as a basic filter on a per 
interface basis to pass or drop packets going in or out of a port. In the 
outbound direction, a packet is subjected to firewall inspection before 
filtering by an ACL. Inbound, a packet is filtered by an ACL then the firewall. 



Be aware that if the firewall is enabled on an interface, ACLs should not 
be used on that interface so that all checks can be performed in one place. 



The XSR provides configuration objects which, used in policy rules, can be 
specified at the CLI. These and other firewall commands are, as follows: 

□ Network - Identifies a network or host. A network with a subnet 

address or a host with an address and 32-bit mask is specified with ip 
firewall network. The command also configures a network or host 
residing on the trusted /internal or un-trusted/ external network. 
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CAUTION 



Use care not to overlap internal and external address ranges since internal 
ranges take precedence over external ranges, and if an address exists in both 
ranges, the internal address will be considered for policy matching. In 
certain situations this may cause unexpected results, specifically if the other 
address in a policy is also internal and you expect a match for a policy rule 
to use that internal address against a wildcard such as ANY_EXTERNAL as 
the second address. This rule will not be matched if the address you expect 
to be part of ANY_EXTERNAL is also defined in an internal address range. 



You can configure a network object from an internal address to any 
address on the Internet as follows: 

XSR (conf ig) #ip firewall network Any_address 1.0.0.1 255.255.255.254 
external or 

XSR (conf ig) #ip firewall network Internet 0.0.0.0 mask 0.0.0.0 external 

□ Network group - Defines a group of network objects. You can group up 
to ten network objects for simpler configuration referenced by a 
single name with ip firewall network -group. The intrinsic, pre- 
defined ANY_EXTERNAE and ANYJNTERNAL groups are 
maintained automatically by the firewall as long as you have defined 
at least one other internal or external group. 

□ Service - Specifies an application in terms of the protocol and source 
and destination ports it uses with ip firewall service . Packets 
with the source port in the specified range will match this service as 
will packets with the destination port. TCP and UDP protocols are 
supported. Intrinsic services for all ports are ANY_TCP for TCP port 
ranges, and ANY_UDP for UDP port ranges. 

□ Service group - Aggregates a number of service objects with ip 
firewall service-group. Typically, the service-group name is the 
specified application. Up to 10 service objects can be grouped. 

□ Policy - Defines which applications can traverse the firewall and in 
which direction with ip firewall policy. Packets which match 
addresses and service are processed by these actions: allow, allow-auth, 
reject, log, reject, els, etc. Configuration must observe these rules: 

- Any address combination - You can define network addresses as 
follows: external to internal, internal to external, and internal to 
internal. External to external is not supported. 

- Rule order - Earlier entered rules take precedence. 

Deny All for Unicast packets - The XSR firewall observes a DENY 
ALL default policy. So, unless explicitly allowed, all packets are 
dropped both ways. 
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- You should set a rule at the end of your configuration to handle 
default behavior in a specific direction. For example, in order to 
allow all packets from internal to external except for Telnet and 
FTP packets, rules for these applications must be defined first. 

Then you must define a rule allowing access to ANY_INTERNAL 
source and ANY_EXTERNAL destination for any service. These 
values are case-sensitive. 

Non-Unicast packet handling - Packets with broadcast or multicast 
destination addresses are not allowed to pass in either direction - 
they must be allowed explicitly. 

This rule makes it easy to deny access to IP broadcast/ multicast 
packets through the firewall but to allow access, you must issue 
the ip firewall ip-broadcast or ip firewall ip-multicast 
commands as well as set policy. 

- IP Packets with options - Packets with options are dropped either 
way by default. You must permit options explicitly either way. 

□ Naming conventions - Any firewall object name must use these alpha- 
numeric characters only: A - Z (upper or lower case), 0 - 9, - (dash), or 
_ (underscore). Also, all firewall object names are case-sensitive. 

□ TCP/UDP/ICMP Filter - Specifically filters TCP, UDP, or ICMP packets 
and assigns an idle session timeout for their inspection, enter ip 
firewall tcp, ip firewall udp, and ip firewall icmp. 

□ Non-TCP '/UDP Filter - Defines packet filtering of non-TCP and UDP 
protocols with ip firewall filter. Because these packets are 
dropped by default, to allow any other IP protocol packet to pass 
through the firewall you must specify a filter object with the correct 
source/ destination IP address and IP protocol ID. 

□ Java and ActiveX - Allows HTML pages with Java and ActiveX content 
through the firewall with the ip firewall java and ip firewall 
activex commands. Options include allowing from all or selected IP 
addresses, or denying from any IP address. 

□ System Filter - Specifies Interface mode filtering with the ip 
firewall ip-options (for loose or strict routing through the 
Internet, trace routes or record time stamps), ip-broadcast (for 
DHCP, e.g.), and ip-multicast (for routing) commands. 

□ Enable/Disable - Turns firewall on or off with ip firewall {enable | 
disable}. The firewall is set per interface or globally and is disabled 
on all interfaces, by default. If the firewall is globally disabled, a local 
enable is ignored and if globally enabled, all interfaces are "on" 
unless you specifically disable each interface. Enable displays in the 
running-conf ig file, but not disable. 
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□ Load - Installs the completed firewall configuration in the XSR's 
inspection engine with ip firewall load. This command avoids 
conflicts with existing sessions by clearing them. But, before doing so 
you can perform a trial load to verify settings or configure 
incrementally and check for errors between loads. You can view 
modified settings before loading with show ip firewall conf ig. 
Also, the delay load option schedules a load and show ip firewall 
general displays an outstanding delay and when it will run. Be 
aware that you must copy the running - conf ig to startup -conf ig 
file to save any changes. Commands entered at the CLI are not in the 
configuration until the load command is invoked, so if you omit a 
load and save the running- to startup -conf ig file, the commands 
you entered will not display. Several other show commands display 
various objects that are in effect, that is, those that have been loaded 
(refer to the following bullet). 



Performing a load requires that you re-establish all TCP connections 
including Telnet sessions and PKI links to the Certificate Authority. Also, 
firewall configuration changes are blocked during a load delay. 



□ Display Commands - A host of firewall show commands are available 
to display firewall attributes for each firewall configuration 
command. Also, show ip firewall conf ig displays the as yet un- 
committed configuration, show ip firewall sessions displays 
dynamic TCP, UDP and ICMP session data, and show ip firewall 
general displays summary system firewall statistics such as the 
status of the firewall, protected and unprotected interfaces, sessions 
counters, and number of DoS attacks. 

□ Event Logging - Defines the event threshold for firewall values logged 
to the Console or Syslog with ip firewall logging. You can set 
eight severity levels ranging from 0 for emergency alarms down to 7 
which cumulatively logs all firewall messages through 0, as follows: 

- Level 0: Emergency 

- Level 1: Alert 

Level 2: Critical - alarms such as failure to allocate memory during 
initializiation are logged if system logging is enabled and firewall 
logging is set to level 2 or higher 
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- Level 3: Error - abnormal and deny alarms are logged if system 
logging is set at MEDIUM or HIGH and firewall logging is level 3 
or higher 

- Level 4: Warning - normal and permit alarms are logged if system 
logging is set at LOW and firewall logging is level 4 or higher 

Level 5: Notice 

- Level 6: Information 

- Level 7: Debug 

You can generate fewer firewall alarms by setting a low logging level 
with the system logging command. 

To further minimize alarms and overhead for the XSR, configure the 
firewall alarm level to 0 with the ip firewall logging command. 
This value is independent of the XSR logging priority, and taking this 
action avoids generating firewall alarms that are later dropped 
anyway by the XSR's system alarm logging mechanism. 

□ Authentication - Defines firewall authentication with idle timeout and 
port range values with ip firewall auth. Also, the ip firewall 
policy command applies authentication rules on a group basis. 
Authentication entries for users are configured using the AAA 
commands including aaa user and password, aaa group, aaa 
policy, and aaa client. When configuring the firewall policy 
group _name, be sure it matches the AAA group name. 
When entering the telnet <address> <port-number> command, 
the screen shown in Figure 56 appears. Be aware that configured 
usernames and passwords must be less than 32 characters and can 
include non-alphanumeric characters. 



Please provide username and password. 
Username : clarkkent 
Password : ****** 
Authenticated . 



XSR>,186>Mar 4 22:56:20 10.10.10.20 CLI: User: clarkkent 

logged in from address 10.10.10.10. 

XSR> 

Figure 56 Sample Telnet Screen 

Be aware that a Telnet session left idle for more than one minute is 
terminated by default. Set the idle timeout with session- timeout. 
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Firewall Limitations 

Consider the following caveats regarding firewall operations: 

□ Gating Rules - Internal XSR gating rules, which order traffic filtering, 
are stored in a temporary file in Flash. Because one gating rule exists 
for each network source/ destination expansion, a potentially 
enormous number of rules can be generated by just a single firewall 
policy For example, when a large network that has an 
ANY_INTERNAL group with 200 network addresses is used as the 
source address, and another group of 10 network addresses is used as 
the destination address, 2000 gating rules are defined for the policy 
Accordingly, a limit is applied to their total, depending on the 
amount of installed RAM (Refer to Table 13). Also, be aware that each 
bidirectional policy produces two gating rules per address pair. 

Because gating rules must be unique, those policies which create 
multiple gating rules when source or destination addresses are 
network group objects will have a gating rule extension appended to 
the actual policy name that was entered in the CLI command. 
Firewall log messages specifying the policy name will display the 
following, for example: 

Log: TCP, Policy PintExtFtpO -2, 10 . 10 . 10 . 100 (1033 ) - > 
20.20.20.100(21) where p-intExtFtp is the CLI policy name and 
_0-2 is the gating rule extension. 

□ Memory Limits - The number of permitted firewall objects are 
constrained by the size of installed RAM in the XSR as follows: 



Table 13 Firewall Limitations 



Firewall Objects 


XSR 1800 
©32MB 


XSR 1800 
©64MB 


XSR 18/3000 
@128 


XSR 3000 
@256 


Networks 


20 


400 


600 


1000 


Services 


50 


400 


600 


1000 


Network Groups 


5 


100 


200 


500 


Service Groups 


10 


100 


200 


500 


Policies 


30 


500 


1000 


3000 


Filters 


30 


500 


1000 


3000 
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Table 13 Firewall Limitations 



Firewall Objects 


XSR 1800 
©32MB 


XSR 1800 
©64MB 


XSR 18/3000 
@128 


XSR 3000 
@256 


Sessions 


250 


10000 


20000 


60000 


Authentications 


75 


150 


300 


1000 


Gating Rules 


300 


5000 


10000 


12000 


External Hosts 


250 


5000 


5000 


20000 


Fragment Table 


50 


100 


200 


600 


FTP Requests 


20 


400 


600 


1000 


UDP Requests 


20 


400 


600 


1000 


Timers 


20 


100 


200 


200 


Java & ActiveX 


20 


100 


200 


200 



□ Session Timeouts - Idle timeout defaults for the three firewall session 
types are enforced as follows: 

TCP idle timeout sessions: 3600 seconds 
- UDP and ICMP idle timeout sessions: 60 seconds 

□ Pre-defined Services - Some pre-defined firewall services may not work 
with applications which use dynamic source ports greater than 1024. 
As a workaround, specify a user- defined service to cover a wider 
source port range. 

□ SNMP - SNMP is not supported for configuration, data and traps. 

□ ACL/Firewall - Access Control Lists (ACLs) are supported for security 
on a per interface basis. Interface ACLs allow or drop packets 
traversing the port in a specified direction (in or out). Heading 
outbound, packets face firewall inspection before ACLs. Going 
inbound, packets first face ACLs, followed by the firewall. So, if the 
firewall is enabled on an interface, we recommend ACLs not be used 
on that port so that all checks can be performed in one place. 

□ Firewall/NAT - On outgoing packets, stateful inspection is preformed 
before NAT. This is due to the fact that NAT modifies the source 
address of all packets to the XSR/s address and policy rules are 
defined with respect to internal and external addresses. On incoming 
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packets, NAT is performed before firewall inspection. Firewall rules 
are written using the actual addresses on the internal (even if they are 
private IP addresses) and exterior networks, independent of whether 
NAT is enabled on the interface. 

□ Firewall/VPN - VPN tunnels are implemented as virtual interfaces 
that sit on physical interfaces. Stateful inspection is applied before 
encryption and encapsulation for outgoing packets and after de- 
encapsulation and decryption for incoming packets. 

□ Firewall and Un-numbered Interface - The firewall does not interoperate 
with interface IP addresses - it is concerned with IP addresses in 
packets that traverse an interface. So, if the firewall is enabled on an 
un-numbered interface, it performs similarly as on a numbered one. 

□ Firewall/VRRP - The firewall does not interoperate with the Virtual 
Router Redundancy Protocol (VRRP). That is, if a switch-over occurs, 
the firewall sessions and authentication cache will not automatically 
switch over. If the firewall is enabled on a slave router, then all 
sessions would have to be re-established. You would have to re- 
authenticate users for access to authentication-protected servers. 

□ Load Sharing - If two or more firewall-enabled XSRs are connected, 
load sharing is not supported. Each XSR would act as a discrete 
firewall and monitor sessions that pass through it. 

□ Secondary IP Address/Firewall - The firewall does not interoperate with 
interface IP addresses, so, a secondary interface address has no affect 
on firewall operations. Configure network objects for the secondary 
address just as you would any primary IP address. 

□ Firewall Authentication over VPN - Firewall authentication is not 
supported over VPN tunnels. 
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Pre-configuring the Firewall 

We recommend you consider the following suggestions to set up the firewall: 

□ Establish a security plan by: 

- Examining your network topology 

Determining exactly what resources you want to protect 

- Deciding where on the network to enable the firewall and plan 
on writing a Telnet or SSH policy for remote administration if 
you are configuring an XSR located in the field 

- Making a list of internal addresses 

- Forming an inventory of desirable applications the firewall will 
allow between protected and external networks 

□ Look up official port numbers of well-known applications at: 
http:/ / www.iana.org/ assignments /protocol-numbers 

The show ip firewall session command also lists these numbers. 

□ Refer to "Firewall Limitations" on page 335 before configuration 

Steps to Configure the Firewall 

Follow the procedure below to configure the firewall: 

□ Specify the network objects 

□ Specify network-group, service and service group objects 

□ Specify policies for TCP and UDP. Remember, the order is important 
and objects and names are case-sensitive 

□ Specify filters for other protocols (ICMP, OSPF, ESP, etc.) 

□ Set miscellaneous parameters such as: 

- TCP, UDP or ICMP session timeouts 
Logging event-levels 0-7 

- Authentication service for users 

- Java and ActiveX filtering 

- IP options filtering on the interface such as time-stamps, route 
recording, and loose or strict routing through the Internet 

- Multicast or broadcast filtering for routing and communications 
protocol filtering 

□ Perform a trial or delayed load to check for configuration errors 
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□ Load the configuration in the firewall engine 

□ Enable or disable the firewall: 

- System wide, or on 

- Individual interfaces or sub-interfaces 

□ After the firewall is installed, check event logging to examine blocked 
traffic for any missed applications rules 

□ Use port scanning tools to ensure policies are properly implemented 



The following sample configurations describe step-by-step how to set up 
these firewall scenarios: 

□ XSR with firewall on page 339 

□ XSR with firewall, PPPoE, and DHCP on page 342 

□ XSR with firewall and VPN on page 344 

□ Firewall configuration for VRRP on page 352. 

□ Firewall configuration for RADIUS authentication on page 352. 

□ Simple security on page 353. 

XSR with Firewall 

In this scenario, the XSR acts as a router connecting a branch office to the 
Internet, as illustrated in Figure 57. The branch office has two servers (Web 
and Mail) accessible from the external world and an internal network of hosts 
which are protected from the external world by the firewall. The Web and 
Mail servers are part of the DMZ and considered internal by the XSR. Note 
that some commands have been abbreviated. 

This configuration, illustrated in Figure 57, provides private and dmz 
networks with unlimited access between each other while protecting traffic to 
and from the external interface only - this is done by enabling the firewall on 
the external interface only. No policies are defined for traffic between private 
and dmz networks. Also, all Java and ActiveX pages, IP options, IP broadcast 
and multicast packets are banned. 
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Internet 



XSR 



220.150.2.32/28 



Frame Relay SI 
206.12.44.16/28 



FE 

220.150.2.17 



220.150.2.16/28 





220.150.2.35 
FE1 220.150.2.37 



Internal 




220.150.2.36 



Web server 

(HTTP) 
220.150.2.19 



Mail server 
(SMTP) 

220.150.2.18 



Figure 57 XSR with Firewall Topology 

Begin by configuring network objects for private, dmz and Mgmt networks: 

XSR (conf ig) #ip firewall network dmz 220.150.2.16 mask 
255.255.255.240 internal 

XSR (conf ig) #ip firewall network private 220.150.2.32 mask 
255.255.255.240 internal 

XSR (conf ig) #ip firewall network Mgmt 220.150.2.35 mask 
255.255.255.255 internal 

Log only critical events: 

XSR (conf ig) #ip firewall logging event- threshold 2 

Allow ICMP traffic to pass between private, dmz and EXTERNAL networks: 

XSR (conf ig) #ip firewall filter oklCMP private ANY_EXTERNAL 
protocol-id 1 

XSR (conf ig) #ip firewall filter ICMP1 dmz ANY_EXTERNAL protocol-id 1 
XSR (conf ig) #ip firewall filter I CMP 2 ANYEXTERNAL dmz protocol-id 1 

Set policies between the dmz, external and Mgmt networks. Note that policy 
objects and names are case-sensitive and you must cite network names exactly: 

XSR (conf ig) #ip firewall policy exttodmzhttp ANY_EXTERNAL dmz HTTP 
allow bidirectional 
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XSR (conf ig) #ip firewall policy exttodmzsmtp ANY_EXTERNAL dmz SMTP 
allow bidirectional 

XSR (conf ig) #ip firewall policy TelnetSESS private Mgmt Telnet 
allow bidirectional 

Set a policy to allow any traffic to pass from private to EXTERNAL networks: 

XSR (conf ig) #ip firewall policy prvtoextprivate ANY_ I NTE RNAL 
ANY_EXTERNAL allow 

Trial load the completed configuration into the firewall engine, and if 
successful, load the configuration: 

XSR (conf ig) #ip firewall load trial 
XSR (conf ig) #ip firewall load 

Complete LAN and WAN interface configuration: 

XSR (conf ig-if<Fl>) #interf ace fastethernet 1 
XSR(config-if<Fl>) #ip address 220.150.2.35 255.255.255.0 
XSR (conf ig-if <F1>) #no shutdown 

XSR (conf ig) #interf ace fastethernet 2 

XSR(config-if<F2>) #ip address 220.150.2.17 255.255.255.0 
XSR (conf ig-if <F1>) #no shutdown 

XSR (conf ig) #interf ace serial 1/0:0 

XSR(config-if<Sl/0:0>) #ip address 206.12.44.16/24 
XSR (conf ig-if <Sl/0 : 0>) #no shutdown 

Globally enable the firewall. Even though you have configured and loaded 
the firewall, only invoking the following command "turns on ,/ the firewall. 
Once enabled, if you are remotely connected, the firewall will close your 
session. Simply login again. 

XSR (conf ig) #ip firewall enable 
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XSR with Firewall, PPPoE and DHCP 

In this scenario, shown in Figure 58, the branch office uses a private address 
for its hosts. Access to the external networkis configured with PPPoE DSL 
service on the FastEthernet 2 interface/ sub-interface and DHCP set on the 
FastEthernet 1 interface. A global IP address is available for a Web server and 
a static NAT entry is set for them. Also, all Java and ActiveX pages, IP 
options, IP broadcast and multicast packets are banned. 

Policies apply to the private addresses as outbound filtering is performed 
before NAT and inbound filtering after NAT. This is key because the firewall is 
oblivious to the global IP address used. Some commands are abbreviated. 




Begin by configuring the LAN interfaces, enabling DHCP, and disabling the 
firewall on both LAN interfaces: 

XSR (conf ig) #interf ace FastEthernetl 

XSR(config-if<Fl>) #ip address 10.10.10.1 255.255.255.0 

XSR (conf ig-if<Fl>) #ip dhcp server 

XSR (conf ig-if<Fl>) #ip firewall disable 

XSR (conf ig-if <F1>) #no shutdown 

XSR (conf ig) #interface FastEthernet2 
XSR (conf ig-if <F2>) #ip firewall disable 
XSR (conf ig-if <F2>) #no shutdown 

Enable the PPPoE interface with a negotiable IP address, adjusted MTU 
packet size, PAP authentication, and NAT enabled: 

XSR (conf ig-if <F2>) #interf ace FastEthernet 2.1 
XSR (conf ig-if ) #encapsulate ppp 
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XSR (conf ig-if ) #ip address negotiated 
XSR(config-if ) #ip mtu 1492 

XSR (conf ig-if ) #ip nat source assigned overload 

XSR (conf ig-if ) #ppp pap sent-username bljsSW23 "password is not 

displayed" 

XSR (conf ig-if ) #no shutdown 

Attach a static route to the PPPoE interface and add a local IP pool: 

XSR (conf ig) #ip route 0.0.0.0 0.0.0.0 FastEthernet2 . 1 

XSR (conf ig) #ip local pool myDhcpPool 10.10.10.0 255.255.255.0 

Specify network objects including Mgmt and Ten for SSH and DHCP service: 

XSR (conf ig) #ip firewall network INT_NETS 10.10.10.0 mask 
10.10.10.255 internal 

XSR (conf ig) #ip firewall network MY_EXT 1.0.0.0 255.255.255.254 external 
XSR (conf ig) #ip firewall network Mgmt 10.10.10.1 mask 
255.255.255.255 internal 

XSR (conf ig) #Ip firewall network Ten 10.1.0.0 mask 255.255.0.0 internal 

Set the policies and filters allowing Web, DNS, FTP, SSL, and ICMP traffic 
between ANYJNTERNAL and ANY_EXTERNAL networks. Also write a 
policy for DHCP and SSH access to the XSR. Be sure to install an SSHv2 client 
on your connecting PC. Note that policy objects and names are case-sensitive 
and you must cite network and protocol names exactly: 

XSR (conf ig) #ip firewall policy P_intExtHttp ANY_ I NTE RNAL 
ANY_EXTERNAL WWW allow 

XSR (conf ig) #ip firewall policy P_intExtDns ANY_INTERNAL 
ANY_EXTERNAL DNSUDP allow 

XSR (conf ig) #ip firewall policy P_intExtFtp ANY_INTERNAL 
ANYEXTERNAL FTP allow 

XSR (conf ig) #ip firewall policy P_intExtHttps ANY_ I NT E RNAL 
ANY_EXTERNAL SSL allow 

XSR (conf ig) #ip firewall policy adminSSH ANY_ I NTE RNAL Mgmt SSH allow 
bidirectional 

XSR (conf ig) #ip firewall policy allowDHCP Ten Ten Bootp allow 
bidirectional 

XSR (conf ig) #ip firewall filter F_ECHO_RESP ANY_EXTERNAL 
ANY_ I NTE RNAL protocol -keyword ICMP 0 

XSR (conf ig) #ip firewall filter F_ECHO_REQ ANY_ I NT E RNAL ANY_EXTERNAL 
protocol -keyword ICMP 8 
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Trial load the completed configuration into the firewall engine, and if 
successful, load the configuration: 

XSR (conf ig) #ip firewall load trial 
XSR (conf ig) #ip firewall load 

Configure the DHCP pool, DNS server and related settings: 

XSR (conf ig) #ip dhcp pool myDhcpPool 
XSR (conf ig) #def ault-router 10.10.10.1 
XSR (conf ig) #dns- server 2 09 . 22 6 . 175 . 223 
XSR (conf ig) #domain-name BT_basement 
XSR (conf ig) #lease 1 3 15 

Globally enable the firewall. Even though you have configured and loaded 
the firewall, only invoking the following command "turns on" the firewall. 
Once enabled, if you are remotely connected, the firewall will close your 
session. Simply login again. 

XSR (conf ig) #ip firewall enable 

XSR with Firewall and VPN 

In this scenario, as illustrated in Figure 59, a head-end VPN gateway is 
configured to perform the following: 

- Terminate Network Extension Mode (NEM) and Client mode 
tunnels 

- Terminate remote access L2TP/IPSec tunnels 

- Terminate PPTP remote access tunnels 

Firewall inspection on the public VPN interface (the crypto map 
interface) 

- Firewall inspection on the trusted VPN interface (the connection 
to the corporate network) 

- OSPF routing with the next hop corporate router on the trusted 
VPN interface 

- DF bit clear on the public VPN interface to handle large non- 
fragmentable IP frames 

- OSPF routing over the multi-point VPN interface for other site- 
to-site tunnels 

- Assign the first IP address of the pool to the multi-point VPN 
interface 
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Figure 59 XSR Firewall, VPN and OSPF Topology 



Begin by setting the XSR system time via SNTP. This configuration is critical 
for XSRs which use time-sensitive certificates. 

XSR (conf ig) #sntp-client server 10.120.84.3 
XSR (conf ig) #sntp-client poll-interval 60 

Add four ACLs to permit IP pool, L2TP and NEM traffic: 

XSR (conf ig) #access-list 110 permit ip any 10.120.70.0 0.0.0.255 
XSR (conf ig) #access-list 120 permit udp any any eq 1701 
XSR (conf ig) #access-list 140 permit ip any 172.16.1.0 0.0.0.255 
XSR (conf ig) #access-list 150 permit ip any 192.168.111.0 0.0.0.255 

Define IKE Phase I security parameters with the following two policies: 

XSR (conf ig) #crypto isakmp proposal xp-soho 

XSR (conf ig-isakmp) #hash md5 

XSR (conf ig-isakmp) #lifetime 50000 

XSR (conf ig) #crypto isakmp proposal p2p 

XSR (conf ig-isakmp) #authentication pre- share 

XSR (conf ig-isakmp) #lifetime 50000 

Configure IKE policy for the remote peer: 

XSR (conf ig) #crypto isakmp peer 0.0.0.0 0.0.0.0 
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XSR (conf ig-isakmp-peer) #proposal xp soho p2p 
XSR (conf ig-isakmp-peer) #conf ig-mode gateway 
XSR (conf ig-isakmp-peer) #nat- traversal automatic 

Configure the following IPSec SAs: 

XSR (conf ig) #crypto ipsec transform- set esp-3des-md5 esp-3des esp- 
md5 - hmac 

XSR (cfg-crypto- tran) no set security-association lifetime kilobytes 

XSR (conf ig) #crypto ipsec transform- set esp-3des-sha esp-3des esp- 
sha-hmac 

XSR (cfg-crypto- tran) set security-association lifetime kilobytes 10000 

Configure the following four crypto maps to match ACLs 150, 140, 120, and 110: 
XSR (conf ig) #crypto map test 50 

XSR (conf ig-crypto-m) #set transform-set esp-3des-sha 
XSR (conf ig-crypto-m) #match address 150 

XSR (conf ig) #crypto map test 40 

XSR (conf ig-crypto-m) #set transform-set esp-3des-sha 
XSR (conf ig-crypto-m) #match address 140 

XSR (conf ig) #crypto map test 20 

XSR (conf ig-crypto-m) #set transform-set esp-3des-md5 
XSR (conf ig-crypto-m) #match address 120 
XSR (conf ig-crypto-m) #mode transport 

XSR (conf ig-crypto-m) #set security-association level per-host 
XSR (conf ig) #crypto map test 10 

XSR (conf ig-crypto-m) #set transform-set esp-3des-sha 
XSR (conf ig-crypto-m) #match address 110 

Configure FastEthernet interface 1 to permit multicast packets in and out: 
XSR (conf ig) #interf ace FastEthernetl 

XSR(config-ifFl>) #ip address 96.96.96.7 255.255.255.0 
XSR (conf ig-ifFl>) #ip firewall ip-multicast in 
XSR (conf ig-ifFl>) #ip firewall ip-multicast out 
XSR (conf ig-if Fl>) #no shutdown 

Configure FastEthernet interface 2 with the attached crypto map test: 
XSR (conf ig) #interface FastEthernet2 
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XSR (conf ig-if F2>) #crypto map test 

XSR(config-ifF2>)#ip address 141.154.196.106 255.255.255.192 
XSR (conf ig-if F2>) #no shutdown 

Configure the VPN virtual interface as a terminating tunnel server with IP 
multicast redirection back to the gateway, add an OSPF network with cost 
and disable the firewall: 

XSR (conf ig) #interf ace Vpnl multi-point 

XSR (conf ig-int-vpn) #ip multicast-redirect tunnel -endpoint 
XSR (conf ig-int-vpn) #ip address 10.120.70.1 255.255.255.0 
XSR (conf ig-int-vpn) #ip firewall disable 
XSR (conf ig-int-vpn) #ip ospf priority 10 
XSR (conf ig-int-vpn) #ip ospf network nbma 

Add a default route to the next hop Internet gateway: 

XSR (conf ig) #ip route 0.0.0.0 0.0.0.0 141.154.196.93 

Define an IP pool for distribution of tunnel addresses to all client types: 
XSR (conf ig) #ip local pool test 10.120.70.0 255.255.255.0 

Create hosts to resolve hostnames for the certificate servers for CRL retrieval: 

XSR (conf ig) #ip host parentca 141.154.196.89 
XSR (conf ig) #ip host childca2 141.154.196.81 
XSR (conf ig) #ip host childcal 141.154.196.83 

Clear the DF bit globally: 

XSR (conf ig) #crypto ipsec df-bit clear 

Enable the OSPF engine, VPN and FastEthernet 1 interfaces for routing: 
XSR (conf ig) #router ospf 1 

XSR (conf ig-router) #network 10.120.70.0 0.0.0.255 area 5.5.5.5 
XSR (conf ig-router) #network 96.96.96.0 0.0.0.255 area 5.5.5.5 

Create a group for NEM and Client mode users: 
XSR (conf ig) #aaa group sohoclient 

XSR (aaa-group) #dns server primary 10.120.112.220 
XSR (aaa-group) #dns server secondary 0.0.0.0 
XSR (aaa-group) #wins server primary 10.120.112.220 
XSR (aaa-group) #wins server secondary 0.0.0.0 
XSR (aaa-group) #ip pool test 
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XSR (aaa-group) #pptp compression 
XSR (aaa-group) #pptp encrypt mppe 128 
XSR (aaa-group) #12tp compression 
XSR (aaa-group) #policy vpn 

Configure DEFAULT group parameters including DNS and WINs servers, an 
IP pool, PPTP and L2TP values, and client VPN permission: 

XSR (conf ig) #aaa group DEFAULT 

XSR (aaa-group) #dns server primary 0.0.0.0 

XSR (aaa-group) #dns server secondary 0.0.0.0 

XSR (aaa-group) #wins server primary 0.0.0.0 

XSR (aaa-group) #wins server secondary 0.0.0.0 

XSR (aaa-group) #ip pool test 

XSR (aaa-group) #pptp compression 

XSR (aaa-group) #pptp encrypt mppe 128 

XSR (aaa-group) #12tp compression 

XSR (aaa-group) #policy vpn 

Define a group for remote access XP users including DNS and WINs servers, 
an IP pool, PPTP and L2TP values, and client VPN permission: 

XSR (conf ig) #aaa group XPusers 

XSR (aaa-group) #dns server primary 10.120.112.220 

XSR (aaa-group) #dns server secondary 0.0.0.0 

XSR (aaa-group) #wins server primary 10.120.112.220 

XSR (aaa-group) #wins server secondary 0.0.0.0 

XSR (aaa-group) #ip pool test 

XSR (aaa-group) #pptp compression 

XSR (aaa-group) #pptp encrypt mppe 128 

XSR (aaa-group) #12tp compression 

XSR (aaa-group) #policy vpn 

Configure the local AAA method for shared secret tunnels (NEM and client 
mode tunnels): 

XSR (conf ig) #aaa method local 

XSR (aaa-method-radius) #group DEFAULT 

XSR (aaa-method-radius) #qtimeout 0 

Configure the RADIUS AAA method to authenticate remote access users: 

XSR (conf ig) #aaa method radius msradius default 
XSR (aaa-method-radius) #backup test 
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XSR (aaa-method-radius) #enable 

XSR (aaa-method-radius) #group DEFAULT 

XSR (aaa-method-radius) #address ip-address 10.120.112.179 

XSR (aaa-method-radius) #key welcome 

XSR (aaa-method-radius) #auth-port 1812 

XSR (aaa-method-radius) #acct-port 1646 

XSR (aaa-method-radius) #attempts 1 

XSR (aaa-method-radius) #retransmit 1 

XSR (aaa-method-radius) #timeout 5 

XSR (aaa-method-radius) #qtimeout 0 

Define the Internet as all possible IP addresses: 

XSR (conf ig) #ip firewall network internet 1.0.0.0/32 external 

Define the public VPN interface (crypto map): 

XSR (conf ig) #ip firewall network vpngateway 141.154.196.106 mask 
255.255.255.255 internal 

Define the private VPN interface (traditionally the FastEthernet 1 interface): 

XSR (conf ig) #ip firewall network fl 96.96.96.7 mask 
255.255.255.255 internal 

Define three trusted networks in the enterprise: 

XSR (conf ig) #ip firewall network trusted84 10.120.84.0 mask 
255.255.255.0 internal 

XSR (conf ig) #ip firewall network trusted96 96.96.96.0 mask 
255.255.255.0 internal 

XSR (conf ig) #ip firewall network trustedll2 10.120.112.0 mask 
255.255.255.0 internal 

Specify remote trusted networks from NEM and Client mode tunnels: 

XSR (conf ig) #ip firewall network remotel72 172.16.0.0 mask 
255.255.0.0 internal 

XSR (conf ig) #ip firewall network remotel92 192.168.0.0 mask 
255.255.0.0 internal 

Define the local pool network used for tunnel IP addresses: 

XSR (conf ig) #ip firewall network vsn 10.120.70.0 mask 
255.255.255.0 internal 

Define two networks to be used by OSPF: 
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XSR (conf ig) #ip firewall network ospf 224.0.0.5 224.0.0.6 internal 
XSR (conf ig) #ip firewall network ssr 96.96.96.1 mask 
255.255.255.255 internal 

Define the NetSight network management station: 

XSR (conf ig) #ip firewall network netsight 10.120.84.3 mask 
255.255.255.255 internal 

Build two network groups to collect remote and trusted networks into 
manageable groups: 

XSR (conf ig) #ip firewall network-group trusted trusted84 trusted96 
trustedll2 

XSR (conf ig) #ip firewall network-group remote vsn remotel72 remotel92 

Define service to support IPSec NAT traversal: 

XSR (conf ig) #ip firewall service nattraversal eq 2797 gt 1023 udp 

Define service for ISAKMP: 

XSR (conf ig) #ip firewall service ike eq 500 gt 499 udp 

Define service for L2TP tunnels: 

XSR (conf ig) #ip firewall service 12tp eq 1701 eq 1701 udp 

Define service for RADIUS authentication: 

XSR (conf ig) #ip firewall service radiusauth gt 1023 eq 1645 udp 

Define service for RADIUS accounting: 

XSR (conf ig) #ip firewall service radiusacct gt 1023 eq 1646 udp 

Write policies allowing traffic through the public VPN interface (crypto map): 

XSR (conf ig) #ip firewall policy nattraversal internet vpngateway 
nattraversal allow bidirectional 

XSR (conf ig) #ip firewall policy PPTP internet vpngateway PPTP 
allow bidirectional 

XSR (conf ig) #ip firewall policy ike internet vpngateway ike allow 
bidirectional 

XSR (conf ig) #ip firewall policy 12tp internet vpngateway 12tp 
allow bidirectional 

Allow HTTP and LDAP CRL retrieval out of the public VPN interface: 

XSR (conf ig) #ip firewall policy pki vpngateway internet HTTP allow 
XSR (conf ig) #ip firewall policy ldap vpngateway internet LDAP allow 
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Write policies permitting RADIUS and all TCp and UDP traffic from remote 
VPN networks into the corporate networks: 

XSR (conf ig) #ip firewall policy radiusauth fla trusted radiusauth 
allow 

XSR (conf ig) #ip firewall policy radiusacct fla trusted radiusacct 
allow 

XSR (conf ig) #ip firewall policy ANYTCP remote trusted ANYTCP 
allow bidirectional 

XSR (conf ig) #ip firewall policy ANYUDP remote trusted ANYUDP 
allow bidirectional 

Allow IPSec (protocol 50) traffic from the Internet into the public VPN 
interface: 

XSR (conf ig) #ip firewall filter ipsec internet vpngateway 
protocol-id 50 bidirectional 

Allow GRE traffic from the Internet into the public VPN interface: 

XSR (conf ig) #ip firewall filter gre internet vpngateway protocol - 
id 47 bidirectional 

Allow OSPF through the firewall (trusted VPN interface) to the next hop 
corporate router: 

XSR (conf ig) #ip firewall filter ospfl fl ospf protocol-id 89 
bidirectional 

XSR (conf ig) #ip firewall filter ospf 2 ssr ospf protocol-id 89 
bidirectional 

XSR (conf ig) #ip firewall filter ospf 3 fl ssr protocol-id 89 
bidirectional 

Permit ICMP traffic to flow from the trusted networks, through the VPN 
tunnels, to the remote trusted networks, and back: 

XSR (conf ig) #ip firewall filter icmpl trusted remote protocol -id 
1 bidirectional 

Allow any IP address on the Internet to send ICMP traffic to the public VPN 
interface (the crypto map interface): 

XSR (conf ig) #ip firewall filter icmp2 vpngateway internet 
protocol-id 1 bidirectional 

Load the firewall configuration: 
XSR (conf ig) #ip firewall load 
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Globally enable the firewall. Even though you have configured and loaded 
the firewall, only invoking the following command "turns on" the firewall. 
Once enabled, if you are remotely connected, the firewall will close your 
session. Simply login again. 

XSR (conf ig) #ip firewall enable 

Firewall Configuration for VRRP 

This example briefly configures VRRP advertisements to be sent and received 
on a FastEthernet interface. You must configure two networks and a filter for 
the VRRP protocol (number 112). It is assumed you have already configured 
the Virtual Router and backup VR within the specified IP address range. 

Enable multicasting in both directions on FastEthernet interface 2: 
XSR (conf ig-if<F2>) #ip firewall ip-multicast both 

Configure the IP address of the firewall networks internal! and vrrp, 
specifying a range between 80.0.0.1 and 80.255.255.254 and a multicasting 
host at 224.0.0.18/32, respectively. Finally, add a policy allowing VRRP 
advertisements to pass between private and external networks. 

XSR (conf ig-ifF2>) #ip address 80.0.0.1/8 

XSR (conf ig) #ip firewall network internal2 80.0.0.0 mask 255.0.0.0 
internal 

XSR (conf ig) #ip firewall network vrrp 224.0.0.18 mask 
255.255.255.255 internal 

XSR (conf ig) #ip firewall filter mult2 internal2 vrrp protocol-id 112 

Firewall Configuration for RADIUS Authentication and 
Accounting 

The following sample configuration employs the RADIUS method for AAA 
authentication. The commands in the section below configure Steel Belted 
RADIUS (SBR) as the RADIUS method, the server's IP address and encryption 
key, its RADIUS authentication and accounting ports (per IANA), and all four 
client services. Also configured are the backup RADIUS server msradius with 
one login attempt specified before the backup is accessed and five retransmit 
requests specified for service, and reconfigured queue and timeout values. 

XSR (conf ig) #aaa method radius sbr default 
XSR (aaa-method-radius) #backup msradius 
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XSR (aaa-method-radius) #address ip-address 10.10.10.1 

XSR (aaa-method-radius) #key acevpnfqwe 

XSR (aaa-method-radius) #client vpn 

XSR (aaa-method-radius) #client telnet 

XSR (aaa-method-radius) #client firewall 

XSR (aaa-method-radius) #client ssh 

XSR (aaa-method-radius) #auth-port 1812 

XSR (aaa-method-radius) #acct-port 1813 

XSR (aaa-method-radius) #attempts 1 

XSR (aaa-method-radius) #retransmit 5 

XSR (aaa-method-radius) #timeout 10 

XSR (aaa-method-radius) #qtimeout 0 

Configure RADIUS network objects: 

XSR (conf ig) #ip firewall network internal 10.10.10.0 mask 
255.255.255.0 internal 

Configure policies allowing RADIUS authentication and accounting: 

XSR (conf ig) #ip firewall policy radius internal internal 
Radius allow bidirectional 

XSR (conf ig) #ip firewall policy RADIUSacct internal internal 
RadiusACCT allow bidirectional 

Configuring Simple Security 

The following configuration provides simple protection for the XSR. The 
firewall feature set is not implemented. 

First, perform standard port configuration: 
XSR (conf ig) #interf ace FastEthernet 1 

XSR(config-if<Fl>) #ip address 192.168.10.1 255.255.255.0 

XSR (conf ig-if <F1>) #no shutdown 

XSR (conf ig) #controller tl 0/2/0 

XSR (conf ig-controller<Tl/2>) #no shutdown 

XSR (conf ig) #interf ace serial 2/0:0 

XSR (conf ig-if <S2/0 : 0>) #encapsulation ppp 

XSR(config-if<S2/0:0>) #ip add 192.168.20.10 255.255.255.0 
XSR (conf ig-if <S2/0 : 0>) #no shutdown 

Formulate access lists of allowed and prohibited network addresses: 
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XSR (conf ig) #access-list 1 permit 192.168.10.0 0.0.0.255 
XSR (conf ig) #access - list 1 permit 192.168.20.0 0.0.0.255 
XSR (conf ig) #access-list 2 permit host 192.168.9.32 
XSR (conf ig) #access-list 100 deny ip any host 192.168.1.15 
XSR (conf ig) #access-list 100 deny any host 192.168.1.15 any 
XSR (conf ig) #access-list 100 deny ip tcp host 192.168.1.15 any 
XSR (conf ig) #access-list 100 permit ip 192.168.1.0 0.0.0.255 any 
XSR (conf ig) #access-list 100 permit ip any 192.168.1.0 0.0.0.255 

Apply the access list to the network interfaces so that everything that is not 
permitted will automatically be filtered out, by default. 

XSR (conf ig) #interf ace fastethernet 1 

XSR (conf ig-if<Fl>) #ip access-group 1 in 

XSR (conf ig-if<Fl>) #ip access-group 1 out 

XSR (conf ig) #interf ace serial 2/0:0 

XSR (conf ig-if<S2/0 : 0>) #ip access-group 1 in 

XSR (conf ig-if<S2/0 : 0>) #ip access-group 1 out 

For security reasons, you can limit the traffic type to certain 
ICMP/UDP/TCP/AH, ESP, and GRE ports. To use traffic type as a criteria, 
enter the extended access -list command, with numbers ranging from 100 
to 199. The standard access - list command employs numbers ranging from 
1 to 99 and can filter traffic by source IP address(es) only. 

Write ACLS to permit Telnet and HTTP sessions. When the access list is 
applied to the port only, this type of traffic is allowed to pass through. 

XSR (conf ig) #access-list 100 permit tcp any any eq 21 
XSR (conf ig) #access-list 100 permit tcp any any eq 80 

Create a username with an encrypted password (using the secret option) that is 
entered as clear text (using the 0 option). 

XSR (conf ig) #username larry password secret 0 larryj 
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This appendix describes the configuration and memory limits of the 
XSR as well as system High, Medium and Low severity alarms and events 
and Firewall /NAT alarms captured by the router. 

System Limits 

The XSR-1805 proscribes limits on the following configurable functions. 



Table 14 XSR Limits 



Function 


©64MB 


@128 MB 


©32MB 


Dynamic ARP entries 


516 


2000 


516 


Max Unresolved ARP Requests 


500 


500 


500 


Routing table entries 


10000 


12000 


2000 


Static routes 


256 


3500 


50 


Static ARPs 


200 


200 


200 


IP Helper addresses 


50 


50 


50 


Secondary IP addresses 


10 


10 


10 


Virtual IP addresses 


44 


44 


44 


UDP broadcast forwarding entries 


50 


50 


50 


OSPF LSA type 1 


500 


500 


100 


OSPF LSA type 2 


500 


500 


100 


OSPF LSA type 3 


500 


3500 


100 
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Table 14 XSR Limits (Continued) 



Function 


@ 64 MB 


@128 MB 


@ 32 MB 


OSPF LSA type 4 


500 


3500 


100 


OSPF LSA type 5 


750 


3500 


750 


OSPF LSA type 7 


250 


250 


250 


ACL list entries 


500 


1000 


500 


Users 


25 


25 


25 


SNMP read-only communities 


20 


20 


20 


SNMP read-write communities 


20 


20 


20 


SNMP trap servers 


20 


20 


20 


SNMP users 


25 


25 


25 


SNMP groups 


100 


100 


100 


SNMP views 


50 


50 


50 


Interfaces 


136 


136 


42 


AAA sessions 


300 


1500 


75 with Routing & VPN or 36 
with VPN & Firewall 


Authenticated tunnels 


200 


1000 


50 with Routing & VPN or 24 
with VPN & Firewall 


IKE/IPSec tunnels (non-authenticated) 


300 


1500 


75 with Routing & VPN or 36 
with VPN & Firewall 


ISAKMP SAs 


600 


3000 


150 with Routing & VPN or 
72 with VPN & Firewall 


ISAKMP proposals 


15 


15 


1 5 with Routing & VPN or 1 0 
with VPN & Firewall 


IPSec SAs 


1200 


3000 


300 with Routing & VPN or 
144 with VPN & Firewall 


L2TP tunnels 


300 


1500 


75 with Routing & VPN or 36 
with VPN & Firewall 


PPTP tunnels 


255 


255 


75 with Routing & VPN or 36 
with VPN & Firewall 


Dialer pool size 


48 


48 


16 with Routing & VPN or 
Routing & Firewall 
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Table 14 XSR Limits (Continued) 



Function 


©64MB 


@128 MB 


©32MB 


Dialer map classes 


192 


192 


64 with Routing & VPN or 
Routing & Firewall 


Frame Relay map classes 


30 


30 


30 with Routing & VPN or 
Routing & Firewall 


RIP networks 


300 


300 


31 


Dynamic NAT sessions 


4095 




4095 


NAT static one-to-one mappings 


1000 




1000 


Firewall networks 


400 


600 


Any firmware option: 20 


Firewall services 


400 


600 


Any firmware option: 50 


Firewall network groups 


100 


200 


5 with Routing & Firewall or 
VPN & Firewall 


Firewall service groups 


100 


200 


10 with Routing & Firewall or 
VPN & Firewal 


Firewall policies 


500 


1000 


10 with Routing & Firewall or 
VPN & Firewal 


Firewall filters 


500 


1000 


30 with Routing & Firewall or 
VPN & Firewal 


Firewall sessions 


10000 


20000 


250 with Routing & Firewall 
or VPN & Firewal 


Firewall authentications 


150 


300 


75 with Routing & Firewall or 
VPN & Firewal 


Firewall Gating Rule Limits 


3000 


5000 


150 with Routing & Firewall 
or VPN & Firewal 
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Alarms and Events 

The XSR exhibits the following alarm logging behavior: 

Table 15 Alarm Behavior 



When alarm logging is set to: 


The XSR-1805 will log: 


HIGH 


HIGH severity alarms only 


MEDIUM 


MEDIUM and HIGH severity alarms 


LOW 


LOW, MEDIUM, and HIGH severity alarms 


DEBUG 


all alarms 



Refer to the table below for all High severity alarms and events reported by 
the XSR. All of the following messages are USER_LEVEL facility except for 
those in bold and red text which are SECURITY_LEVEL. 



Table 16 High Severity Alarms/Events 



Module 


Message 


Description 


WEB 


Failed to enable Web server 


HTTP server is not enabled properly - cannot accept client connection 


WEB 


Failed to enable Web server 


HTTP server is not enabled properly - cannot listen to incoming 
requests 


WEB 


Failed to enable Web server 


HTTP server is not enabled properly - cannot set socket options 


WEB 


Failed to enable Web server 


HTTP server is not enabled properly - cannot bind socket 


WEB 


Failed to enable Web server 


HTTP server is not enabled properly - cannot listen to socket 


Various 
modules 


Interface interface name>, changed 
state to up 


An interface link comes up 


Various 
modules 


Interface interface name>, changed 
state to down 


An interface link goes down 


T1E1 


Receiver has Loss of Frame (Yellow 
Alarm). 


Indicates that T1/E1 physical port is detecting OOF Alarm. 
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Table 16 High Severity Alarms/Events (Continued) 



Module 


Message 


Description 


T1E1 


LOF alarm on receiver cleared. 


Indicates that T1/E1 physical port is not detecting OOF Alarm. 


T1E1 


Transmiting Remote Alarm (Yellow 
Alarm). 


Indicates that T1/E1 physical port is transmitting remote alarm. 


T1E1 


Transmit Remote Alarm cleared. 


Indicates that T1/E1 physical port is not transmitting remote alarm. 


SYNC_ 
DRIV 


The ISR could not be connected 


The driver failed to connect the ISR to the BSP, therefore it will not be 
started 


SYNC_ 
DRIV 


Init string parse failure 


The driver could not parse the initialization string and therefore it will 
not be started 


SYNC_ 
DRIV 


Unrecoverable error 


The device has an un-recoverable error 


SYNC_ 
DRIV 


OS initialization failure 


The operating system failed to initialize the driver properly, therefore 
the device cannot be started. 


SYNC_ 
DRIV 


Device not found 


The device could not be found on the PCI bus, so the driver cannot be 
started 


SNMP 


Failed to enable SNMP server 


Failed to start SNMP server due to failed in the locking mechanism or 
the message queue is full. 


SNMP 


Failed to disable SNMP server 


Failed to start SNMP server due to failure in the locking mechanism. 


PLATF 


System reset from <reason>, 
<warm|cold> start 


"Warm start, cold start with following reasons: 

- default config init ""dcfg"" 

- crash reset "crsh "" 

- cli reset ""cli "" 

- SNMP reset "snmp"" 

- bootrom reset "btrm"" 

- software checksum invalid ""cksm"" 


PLATF 


Failed to initialize sysLog socket 


Cannot create socket for sending syslogs 


PLATF 


Failed to bind to sysLog port 514 


Cannot bind to port 514 for sending syslogs 


ISDN 


<BRI c/p> SPID <spid string> 
Registered (CES<1|2) 


Displayed when BRI with North American switch types registers with 
the central office successfully 


ISDN 


<BRI c/p>, Unsolicited 
SME_TERM_REGISTER_ACK 


Displayed when BRI with North American switch types registers with 
the central office but fails 


ISDN 


<BRI c/p>, Registration Failed, Cause 
<number> 


Displayed when BRI with North American switch types registers with 
the central office and fails. Cause 100: SPID configuration error, 41: 
Network timeout and 1 : Fit timeout 
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Table 16 High Severity Alarms/Events (Continued) 



Module 


Message 


Description 


ISDN 


%s Layer 2 Terminal %d is DOWN 
%s Layer 2 Terminal %d is UP 


Q921 - LAP-D status, UP is normal operation. Terminal is 1 for PRI. 
For BRI it may be 1 or 2. 1 for ETSI and NTT. For North America 1 
and 2 if two SPIDs are configured. 


ISDN 


%s Outgoing Call to %s %s Timed Out 


For basic-NET3 BRI, XSR-1805 was not able to activate the BRI line 
for an outgoing call 


ISDN 


%s Switch Offers call for BUSY channel 

%X 


Error condition! 


ISDN 


Incoming Call <BRI | Serial 
card/port:channel> Connected to 
<calling no.> Unknown Call 


Incoming Call connected for test purposes and will be disconnected 
within 30 seconds. 


ISDN 


North American BRI Interface %d 
requires SPID configuration 


Configuration error. 


ISDN 


Call <BRI | Serial card/port:channel> 
Connected to <called no.> Outgoing 
test CALL 


Test Call placed from the console. 


ISDN 


Call <BRI | Serial card/port:channel> 
Disconnected from <number> 
<Outgoing test CALL | Unknown Call> 
Cause <passed from central office> 


Test call disconnected due to standard ISDN cause. E.g. 16: normal 
clearing, 18: user does not answer. 


ISDN 


No Channel Available destination 
name> 


ISDN line was over subscribed. 


ISDN 


_FILE _LINE Out of memory 


Unable to allocate memory 


ISDN 


ISDN panic!! 


Unable to create ISDN object 


ISDN 


_FILE _LINE Out of memory 


Unable to allocate memory 


ISDN 


_FILE _LINE Out of memory 


Unable to allocate memory 


ISDN 


_FILE _LINE unexpected value 


Unexpected message received 


ISDN 


Interface BRI, changed state to up 


Port has changed to UP state 


ISDN 


Interface BRI, changed state to down 


Port has changed to DOWN state 


Frame Relay 


Serial a/b:d.e, started 


Output from the no shutdown command 


Frame Relay 


Serial a/b:d.e, shutting down 


The interface has been manually shut down 


Frame Relay 


Serial a/b:d.e, station UP, DLCI nnnn 


The network reports station up. 
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Table 16 High Severity Alarms/Events (Continued) 



Module 


Message 


Description 


Frame Relay 


Serial a/b:d.e, station DOWN, DLCI 
nnnn 


The network reports station up. 


Frame Relay 


Serial a/b:d cannot establish LMI, port 
is down 


The network has not been responding for 5 minutes - check 
connection. 


Frame Relay 


Serial a/b:d LMI - port DOWN 


The LMI is reporting the port is Down. 


Frame Relay 


Serial a/b:d LMI - port UP 


The network is reporting the port is Up. 


Frame Relay 


Serial a/b:d.e Config Error Aggregate 
CIR nnnn greater than measured speed 
nnn - CIR Assist is DISABLED 


Total configured CIR exceeds speed of link - cannot guarantee CIR 
and assist will not be operational. 


FTM1 nRI\/ 
C I n I LJrxl V 


1 lie (JcVIL/fci Io oLUL.I\ 111 ItJbtJL 


1 lie rdoldlltJIIltJl £. Ullip UN Lilt; ITlULIlollJUcirU lb t;Xpt;rit;llL.llig bcvclc 

problems, in that it cannot come out of reset. The FastEthernet 2 
driver/interface cannot be started. This most likely cause of this alarm 
is a hardware failure. When this alarm occurs, the FastEthernet 
Interface 2 is not available. 


ETH1_DRIV 


The device TX/RX is stuck in reset 


The FastEthernet 2 chip on the motherboard is experiencing severe 
problems, in that either the transmitter or receiver cannot come out of 
reset. The FastEthernet 2 driver/interface cannot be started. This 
most likely cause of this alarm is a hardware failure. When this alarm 
occurs, the FastEthernet Interface 2 is not available. 


ETH1_DRIV 


The ISR could not be connected 


This is an internal configuration alarm that occurs because the 
interrupt service routine (ISR) cannot be connected to the 
FastEthernet 2 interface/driver. This alarm will cause the 
FastEthernet 2 interface to be unavailable. 


ETH1_DRIV 


In it string parse failure 


This is an internal configuration alarm that occurs because the driver 
could not parse its initialization string. This alarm will cause the 
FastEthernet 2 interface to be unavailable. 


ETH1_DRIV 


Unrecoverable error 


The FastEthernet 2 chip on the motherboard is experiencing severe 
problems, in that it has a catastrophic failure. This most likely cause 
of this alarm is a hardware failure. When this alarm occurs, the 
FastEthernet 2 interface is not available. 


ETH1_DRIV 


OS initialization failure 


This is an internal configuration alarm that occurs because the 
operating system initialization of the driver/interface cannot be 
completed. This alarm will cause the FastEthernet 2 interface to be 
unavailable. 
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Table 16 High Severity Alarms/Events (Continued) 



Module 


Message 


Description 


ETH1_DRIV 


Device not found 


This alarm most likely occurs because of a hardware failure, and 
means that the FastEthernet 2 chip cannot be found on the PCI bus 
(of the motherboard). When this alarm occurs, the FastEthernet 2 
interface is unavailable. 


ETH0_DRIV 


The device is stuck in reset 


The FastEthernet 1 chip on the motherboard is experiencing severe 
problems, in that it cannot come out of reset. The FastEthernet 1 
driver/interface cannot be started. This most likely cause of this alarm 
is a hardware failure. When this alarm occurs, the FastEthernet 
Interface 1 is not available. 


ETH0_DRIV 


The ISR could not be connected 


This is an internal configuration alarm that occurs because the 
interrupt service routine (ISR) cannot be connected to the 
FastEthernet 1 interface/driver. This alarm will cause the 
FastEthernet 1 interface to be unavailable. 


ETH0_DRIV 


Init string parse failure 


This is an internal configuration alarm that occurs because the driver 
could not parse its initialization string. This alarm will cause the 
FastEthernet 1 interface to be unavailable. 


ETHO DRIV 


OS initialization failure 


This is an internal configuration alarm that occurs because the 
operating system initialization of the driver/interface cannot be 
completed. This alarm will cause the FastEthernet 1 interface to be 
unavailable. 


CLI 


Failed to create session for web access 


Failed to start session for web. 


CLI 


Failed to create session for console 
access 


Failed to start session for web. 


CLI 


Failed to create session for telnet 
access 


Failed to start session for console. 


CLI 


Failed to create session for telnet 
access 


Failed to start session for Telnet. 


CLI 


Failed to enable Telnet server 


Cannot start Telnet server because socket open failed. 


CLI 


Failed to enable Telnet server 


Cannot start Telnet server because socket bind failed. 


CLI 


Failed to enable Telnet server 


Cannot start Telnet server because socket listen failed. 


CLI 


Failed to enable Telnet server 


Failed to enable Telnet server. 


CLI 


CLI Config mode released by user 
<username> 


When a user exits Configuration mode. 
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Table 16 High Severity Alarms/Events (Continued) 



Module 


Message 


Description 


CLI 


CLI Config mode released by user 
<username> 


When a user (unknown) exits Configuration mode. 


CLI 


CLI config mode released by startup- 
config 


Configuration mode is released when the startup-config script finishes 
the execution. 


CLI 


User: <username> logged in from 
address <IP address> 


When login process fails due to invalid user ID or password through 
telnet session in CheckLogin(). 


CLI 


User: <username> logged in from 
console 


When login process fails due to invalid user ID or password through 
console session in CheckLogin(). 


CLI 


Failed to create CLI session 


Insufficient memory at this time for data allocation. 


CLI 


User: <username> failed to log in 
from address <IP address> 


Occurs when the user tries to login to administrator reserved session 
through Telnet and fails due to invalid login ID in lsUserAdmin() 


CLI 


Cannot open startup. cfg file! It may 
have not been generated yet. 


Occurs when user can not open startup configuration file in 
RestoreRunningConfig( ) 


CLI 


Could not seek to the end of startup. cfg 
file! Startup. cfg not restored! 


Could not move to the end of startup configuration file in 
RestoreRunningConfig() 


CLI 


Could not get the size of startup. cfg file! 
Startup. cfg not restored! 


Size of startup configuration file could not be obtained in 
RestoreRunningConfig() 


CLI 


Could not go to beginning of startup. cfg 
file! Startup. cfg not restored! 


In RestoreRunningConfig() 


CLI 


Could not allocate memory for 
startup. cfg file! Startup. cfg not restored! 


Out of memory in RestoreRunningConfig() during boot process 


CLI 


Could not read startup. cfg! Startup. cfg 
not restored! 


Failed reading startup config during boot process 


CLI 


Startup-config error at line <line 
number> 


Startup-config encounters an error at the specified line in the 
configuration file 


CLI 


Running configuration can not be 
restored successfully! 


Failed to restore configuration during boot process 


CLI 


Failed to read CLI configuration files 


Failure during boot process 


CLI 


Line <line #> too long in config file 
configuration file name> Skipping rest 
of file... 


The specific line from startup configuration is too long to be 
processed during boot process 
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Table 16 High Severity Alarms/Events (Continued) 



Module 


Message 


Description 


CLI 


CLI config mode released by user 
<username> 


Occurs when a user (unknown) exits the configuration mode 


CLI 


CLI Config mode locked by user 
<username> 


Occurs when another user is in Configuration mode and you trying to 
get to configuration mode 


CLI 


CLI Config mode locked by startup- 
config 


Configuration mode is locked when the startup-config script finishes 
execution 


CLI 


CLI Config mode released by user 
<username> 


Occurs when a user exits Configuration mode 


CLI 


Cannot delete the Admin 


Occurs when you try to delete the administrator account 


ASYNC_ 
DRIV 


The ISR could not be connected 


The driver failed to connect the ISR to the BSP, therefore it will not be 
started 


ASYNC_ 
DRIV 


Init string parse failure 


The driver could not parse the initialization string and therefore it will 
not be started. 


ASYNC_ 
DRIV 


Unrecoverable error 


The device has an un-recoverable error 


ASYNC_ 
DRIV 


OS initialization failure 


The operating system failed to initialize the driver properly, therefore 
the device cannot be started 


ASYNC_ 
DRIV 


Device not found 


The device could not be found on the PCI bus, so the driver cannot be 
started 



Refer to the table below for all Medium severity alarms and events reported 
by the XSR. All of the following messages are USER_LEVEL facility except for 
those in bold text which are SECURITY_LEVEL. 



Table 17 Medium Severity Alarms/Events 



Module 


Message 


Description 


T1E1 


Not enough memory (Device: card 
number). 


Error in allocating memory for T1 E1 HW card. 


T1E1 


PCI device failure (Device: card 
number). 


Error in initializing T1 E1 HW card. 
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Table 17 Medium Severity Alarms/Events (Continued) 



Module 


Message 


Description 


T1E1 


PCI device failure (Device/Port: card 
number/port number). 


Error in initializing T1 E1 HW card. 


T1E1 


Not enough memory (Device: card 
number). 


Error in allocating memory for T1 E1 HW card. 


T1E1 


Not enough memory (Device/Port: 
card number/port number). 


Error in allocating memory for T1 E1 HW card. 


T1E1 


Internal system error (Device/Port: 
card number/port number). 


Error in initializing T1E1 software. 


T1E1 


Could not register with MIB2 
(Device/Port: card number/port 
number). 


Failed to register T1E1 subsystem with SNMP/MIB2 services. 


T1 


T1E1 PCI Init failed 


Error in initializing T1E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Transmit Pending Queue. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Transmit Done Queue. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Transmit Descriptors. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Receive Free Queue. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Receive Done Queue. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Receive Descriptors. 


Error in allocating memory for T1 E1 HW card. 


T1 


T1E1 PCI Init Failed. 


Error in initializing T1E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Transmit Pending Queue. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Transmit Done Queue. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Transmit Descriptors. 


Error in allocating memory for T1 E1 HW card. 
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Table 17 Medium Severity Alarms/Events (Continued) 



Module 


Message 


Description 


T1 


ERROR: Shared memory allocation 
failed for Receive Free Queue. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Receive Done Queue. 


Error in allocating memory for T1 E1 HW card. 


T1 


ERROR: Shared memory allocation 
failed for Receive Descriptors. 


Error in allocating memory for T1 E1 HW card. 


SNTP 


SNTP request receive-timeout. 


Failed to receive reply time from the server after one second. 


SNMP 


SNMP auth failure from <ip 
address> <community> 


SNMP requested received with invalid community name. The 
community name with a max of 40 characters is displayed. 


SNMP 


SNMP <trapType> trap. No route to 
host <IP address> 


SNMP trap is added to retransmission queue because there is no 
route to the SNMP target server 


SNMP 


CLI config mode locked by SNMP 
user %s\n 


Process SNMP packet and begin to set values on a parameter under 
config mode. 


SNMP 


CLI config mode released by SNMP 
user %s\n 


SNMP finished setting value on a parameter under config mode. 


SNMP 


SNMP <trapType> trap dropped due 
to queue overflow 


Too many traps are sent at a time causing the SNMP trap queue to 
overflow. As a result, the oldest item in the trap queue were dropped. 


SNMP 


No SNMP host is defined, traps are 
queued 


SNMP trap is enabled but trap target server is not defined 


SNMP 


SNMP <trapType> trap dropped when 
trying to send, cause unknown 


Failed to send snmp trap to the trap target server. The cause of failure is 
unknown 


SNMP 


SNMP <trapType> trap. No route to 
host <ip address> 


SNMP trap is added to retransmission queue because there is no route to 
the SNMP target server 


PPP 


PPP CHAP authentication failed while 
authenticating remote peer's response 


Indicates that PPP CHAP authentication has failed while authenticating 
remote peer's response to the challenge. 


PPP 


PPP CHAP authentication failed while 
being authenticated by remote peer 


Indicates that PPP CHAP authentication has failed while being 
authenticated by the remote peer. 


PPP 


PPP CHAP authentication success 
while authenticating remote peer's 
response 


Indicates that PPP CHAP authentication has passed while authenticating 
remote peer's response. 


PPP 


PPP CHAP authentication success 
while being authenticated by remote 
peer 


Indicates that PPP CHAP authentication has passed while being 
authenticated by the remote peer. 
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Module 


Message 


Description 


ppp 


PPP MS-CHAP authentication failed 
while authenticating remote peer's 
response 


Indicates that PPP MS-CHAP authentication has failed while 
authenticating remote peer's response to the challenge. 


ppp 


PPP MS-CHAP authentication failed 
while being authenticated by remote 
peer 


indicates that PPP MS-CHAP authentication has failed while being 
authenticated by the remote peer. 


ppp 


PPP MS-CHAP authentication 
success while authenticating remote 
peer's response 


Indicates that ppp ms-chap authentication has passed while 
authenticating remote peer's response. 


ppp 


PPP MS-CHAP authentication 
success while being authenticated by 
remote peer 


Indicates that PPP MS-CHAP authentication has passed while being 
authenticated by the remote peer. 


ppp 


PPP PAP authentication failed while 
authenticating remote peer 


Indicates that PPP PAP authentication has failed while authenticating 
remote peer. 


ppp 


PPP PAP authentication failed while 
being authenticated by remote peer 


Indicates that PPP PAP authentication has failed while being 
authenticated by the remote peer. 


ppp 


PPP PAP authentication success 
while authenticating remote peer 


Indicates that PPP PAP authentication has passed while authenticating 
remote peer. 


ppp 


PPP PAP authentication success 
while being authenticated by remote 
peer 


Indicates that PPP PAP authentication has passed while being 
authenticated by the remote peer. 


ppp 


Line protocol on Interface interface 
name>, changed state to up 


A line protocol on an interface comes up 


ppp 


Line protocol on Interface <interface 
name>, changed state to down 


A line protocol on an interface goes down. 


PLATF 


Failed to set syslog rx buf to zero 


Cannot set recv buffer to zero to discard received syslogs 


ISDN 


Incoming Call <BRI | Serial 
card/port:channel> Connected to 
<calling no.> destination name> 


Incoming call connected to the shown channel. 


ISDN 


Call <BRI | Serial card/port:channel> 
Connected to <called_no> 
destination name> 


Test call disconnected due to standard ISDN cause. E.g. 16: normal 
clearing, 18: user does not answer 
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Table 17 Medium Severity Alarms/Events (Continued) 



Module 


Message 


Description 


ISDN 


Call <BRI | Serial card/port:channel> 
Disconnected from <number> 
destination name> Cause <passed 
from CO> 


Call disconnected, the cause is the standard ISDN cause. E.g. 16 normal 
clearing, 18 User does not answer 


Frame 
Relay 


Serial a/b:d Config Good Aggregate 
CIR nnn less than measured 
speed+D137 nnnn - CIR Assist is 
ENABLED 


Total configured CIR is within 125% of the port measured speed - CIR 
assisting is enabled. 


ETH0_ 
DRIV 


PHY read operation time-out 


This alarm occurs because the PHY chip on the FastEthernet 1 interface 

lido CAfJcllcllOcU d UllltJ-UUl Willie piUL/Cbblliy d IfcidU IfciqUfciol.. VVIlcll LI Ho 

alarm occurs, the functionality of this interface may or may not be 
affected. The interface will still be available, but it's functionality may be 
diminished. The cause of this alarm is most likely HW failure. 


ETH0_ 
DRIV 


PHY read operation unsuccessful 


This alarm occurs because the PHY chip on the FastEthernet 1 interface 

lido cXpclltJIlt/tJU dll tJIIUI ^ULIltJI llldll LlllltJ-UULj Willie pi(JL.fcioolliy d IfcidU 

request. When this alarm occurs, the functionality of this interface may or 
may not be affected. The interface will still be available, but its 
functionality may be diminished. The cause of this alarm is most likely HW 
failure. 


ETH0_ 
DRIV 


PHY write operation time-out 


This alarm occurs because the PHY chip on the FastEthernet 1 interface 

hoc ovnciridnpciH o timo r\\ if \A/hil^ nrn^Qccinn o \ m r'\\ c± r&ni loot \A/h^n fhic 
lido cXpclltJIlUtJU d llllltJ-UUl Wllllt; piUOfcioolliy d Wlllc IcLjUcoL. vVlltJIl llllo 

alarm occurs, the functionality of this interface may or may not be 
affected. The interface will still be available, but its functionality may be 
diminished. The cause of this alarm is most likely HW failure. 


ETH0_ 
DRIV 


PHY write operation unsuccessful 


This alarm occurs because the PHY chip on the FastEthernet 1 interface 
has experienced an error (other than time-out) while processing a write 
request. When this alarm occurs, the functionality of this interface may or 
may not be affected. The interface will still be available, but its 
functionality may be diminished. The cause of this alarm is most likely HW 
failure. 


DIAL 


Dial muxloctl call fail 


Indicates the failure of the serial driver of the physical interface connected 
to the modem 


DIAL 


Modem on intf # is not responding 


Indicates that the modem is not connected or not powered on 


DIAL 


Invalid init string for modem on intf # 


Indicates that the modem does not recognize the initialization string; 
check the modem specification for a proper setup 


DIAL 


Number busy for modem on intf # 


Indicates that the remote site dialed number is busy 
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Table 17 Medium Severity Alarms/Events (Continued) 



Module 


Message 


Description 


DIAL 


No dial tone for modem on intf # 


Indicates that there is no dial tone for the modem PSTN line 


DIAL 


No carrier for modem on intf # 


Indicates that the remote modem is not present at the location called by 
the local modem 


DIAL 


No answer for modem on intf # 


Indicates that the remote modem is not configured for autoanswering. 


DIAL 


Connection dropped for modem on 
intf#s 


Indicates that the phone line connection is disconnected by the PSTN. 


DIAL 


Hangup fail for modem on intf # 


Indicates the failure of the disconnect from the phone line command to 
the modem. 


DIAL 


Connection closed for modem on intf # 


Indicates that the phone line disconnect command is successful. 


DIAL 


Dialup connection opened for modem 
on intf # 


Indicates that the modem has successfully established a phone line 
connection with the remote site. 


CLI 


Failed to create session for Telnet 
access 


Telnet session could not be created at this time 


CLI 


Unrecognized parameter <parameter 
string> at line <line #> in <file> 


Invalid parameters from initialization configuration file during boot 
process. This file is different from the startup. cfg 



Refer to the table below for all Low severity alarms and events reported by 
the XSR. All of the following messages are USER_LEVEL facility except for 
those in bold text which are SECURITY_LEVEL. 



Table 1 8 Low Severity Alarms/Events 



Module 


Message 


Description 


T1E1 


Receiver has Loss of Signal (Red Alarm). 


Indicates that T1/E1 physical port is detecting LOS Alarm. 


T1E1 


LOS alarm on receiver cleared. 


Indicates that T1/E1 physical port is not detecting LOS Alarm. 


T1E1 


Receive Remote Alarm Indication (Yellow 
Alarm). 


Indicates that T1/E1 physical port is detecting RAI Alarm. 


T1E1 


Receive RAI alarm cleared. 


Indicates that T1/E1 physical port is not detecting RAI Alarm. 


T1E1 


Receive Alarm Indication Signal (Blue Alarm). 


Indicates that T1/E1 physical port is detecting AIS Alarm. 



XSR User's Guide 



373 



Alarms and Events 



Appendix A 
Alarms/Events and System Limits 



Table 18 Low Severity Alarms/Events (Continued) 



Module 


Message 


Description 


T1E1 


Receive AIS cleared. 


Indicates that T1/E1 physical port is not detecting AIS Alarm. 


T1 


Cablelength long failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Cablelength short failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Bert start failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Bert profile failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Bert abort failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Clear controller counter failed for 
slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Load channel failed for slot/card/port:channel. 


Load command sent to driver returned an error. 


T1 


Unload channel failed for 
slot/card/portchannel. 


Unload command sent to driver returned an error. 


T1 


Start channel failed for slot/card/portchannel. 


Start command sent to driver returned an error. 


T1 


Delete channel interface failed for 
slot/card/portchannel. 


Interface object delete could not be executed. 


T1 


Create channel interface failed for 
slot/card/portchannel. 


Interface object create could not be executed. 


T1 


Clock source failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


CRC failed for slot/card/portchannel. 


Configuration command sent to driver returned an error. 


T1 


FDL failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Framing failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Invert data failed for slot/card/portchannel. 


Configuration command sent to driver returned an error. 


T1 


Linecode failed for slot/card/port. 


Configuration command sent to driver returned an error. 


T1 


Loopback configuration failed for 
slot/card/port. 


Loopback command sent to driver returned an error. 


T1 


Loopback stop failed for slot/card/port. 


Loopback stop command sent to driver returned an error. 


T1 


Load controller failed for slot/card/port. 


Load command sent to driver returned an error. 


T1 


Unload controller failed for slot/card/port. 


Unload command sent to driver returned an error. 


T1 


Start controller failed for slot/card/port. 


Start command sent to driver returned an error. 
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Table 18 Low Severity Alarms/Events (Continued) 



Module 


Message 


Description 


T1 


Stop controller failed for slot/card/port. 


Stop command sent to driver returned an error. 


T1 


Bind controller failed for slot/card/port. 


Bind command sent to driver returned an error. 


T1 


Delete controller object failed for 
slot/card/port. 


T1E1 controller object delete could not be executed. 


T1 


Create controller object failed for 
slot/card/port. 


T1E1 controller object create could not be executed. 


SYNC_ 
DRIV 


Recoverable error 


The device has hard recoverable error. 


SYNC_ 
DRIV 


Packets lost > 255 (RX overrun) 


The number of packets lost due to RX FIFO overrun has 
exceeded 255. 


PP 


Out of memory - frame dropped at port <port 
number> 


When a frame is dropped at the specified port due to out of 
memory. 


PLATF 


Need 'snmp-server system-shutdown' for 
SNMP reboot 


SNMP configuration does not allow reboots. 


Frame 
Relay 


serial a/b:d.e, packet arrived on unconfigured 
DLCI nnnn 


Data is discarded 


ETH1_ 
DRIV 


Recoverable error 


This alarm indicates that the FastEthernet 2 chip (of the 
interface) has experienced a signficant, but recoverable 
problem. The interface has already corrected the problem by 
resetting itself. 


ETH1_ 
DRIV 


Packets lost > 255 (RX overrun) 


The number of packet that this interface has lost (had to discard) 
due to receive FIFO overrun is greater than 255. This alarm will 
only occur once. 


ETH0_ 
DRIV 


Recoverable error 


This alarm indicates that the FastEthernet 1 chip (of the 
interface) has experienced a signficant, but recoverable 
problem. The interface has already corrected the problem by 
resetting itself. 


ETH0_ 
DRIV 


Packets lost > 255 (RX overrun) 


The number of packets that this interface has lost (had to 
discard) due to receive FIFO overrun is greater than 255. This 
alarm will only occur once. 


CLI 


Login failed from address <IP address> due 
to timeout 


Timeout error during login. 
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Table 18 Low Severity Alarms/Events (Continued) 



Module 


Message 


Description 


ASYNC_ 
DRIV 


Recoverable error 


The device has hard recoverable error. 


ASYNC_ 
DRIV 


Packets lost > 255 (RX overrun) 


The number of packets lost due to RX FIFO overrun has 
exceeded 255. 



Firewall and NAT Alarms and Reports 

The XSR reports logging messages for firewall and NAT functionality as 
listed below. Low system-level logging messages are classified at Levels 4 or 6 
while Medium system-level alarms are classified at Level 3. The format codes 
used in report descriptions are defined as follows: 

- %CMD - ACTIVEX, JAVA or CLS application commands 

- %IP1 - 192.168.1.1 

- %IP2 - 192.168.1.1->10.10.10.1 

- %IP_P2 - 192.168.1.1(12352)->10.10.10.1(21) 

- %IP_TC - 192.168.1.1 type 8 code 2 

- %IP2_ICMP - 192.168.1.1->10.10.10.1 type 8 code 0 

- %IP2_X - 192.168.1.1->10.10.10.1 protocol nn 

- %POL - Name of the firewall policy that causes this report 



Table 19 Firewall and NAT Alarms 



Severity 


Report Text 


0- EMERG 


Bad NAT entry pointer passed to freeAddrTransEntry() 


0- EMERG 


Init: Failed to allocate memory for NAT cache 


1 - ALERT 


DHCP module resolved a new IP Address for NAT: %IP1 


1 - ALERT 


DHCP module resolved a new IP Mask for NAT: %IP1 


1 - ALERT 


DHCP module resolved a new router's IP address: %IP1 


1 - ALERT 


NAT: Attempt made to bypass NAT by a GRE packet, %IP2 


1 - ALERT 


NAT: Attempt made to bypass NAT, %IP_P2 
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Table 19 Firewall and NAT Alarms 



Severity 


Report Text 


2 - CRIT 


Init: Error reading NAT Mapper table 


3 - ERROR 


NAT: No NAT entry found, %IP_P2 


3 - ERROR 


NAT: No NAT entry found, %IP_P2 


3 - ERROR 


NAT: TCP reset, NAT port %d, %IP_P2 


3 - ERROR 


UDP: NAT unable to forward packet, %IP_P2 


4- WARNING 


NAT table is full 


4- WARNING 


NAT: TCP connection closed, freeing NAT port %d 


4- WARNING 


Purging NAT Entry for port %d 


5- NOTICE 


NAT: Failed to send ARP Request packet to %\P^ 


5- NOTICE 


NAT: Failed to send ARP Request packet to default router %IP1 


0-EMERG 


Init: Failed to allocate external host memory 


0-EMERG 


Init: Failed to allocate memory for auth host table 


0- EMERG 


Init: Failed to allocate memory for Fragmentation cache 


0-EMERG 


Init: Failed to allocate memory for FTP Request pool 


0-EMERG 


Init: Failed to allocate memory for UDP Request pool 


0-EMERG 


Init: Failed to allocate session memory 


0-EMERG 


Init: Session Mgr Failed to create aging timer 


0-EMERG 


Init: Session Mgr failed to create FloodCheck timer 


1 - ALERT 


Deny: TCP SYN backlog queue is full. %IP_P2 


1 - ALERT 


Deny: TCP SYN+ACK backlog queue is full. %IP_P2 


1 - ALERT 


Empty IP fragment 


1 - ALERT 


External Host pool exhausted 


1 - ALERT 


FTP PORT Command has bad IP Address %IP2 


1 - ALERT 


Init: Error reading ActiveX filter 
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Table 19 Firewall and NAT Alarms 



Severity 


Report Text 


1 - ALERT 


IP fragment offset plus length exceeds the maximum IP datagram 
length 


1 - ALERT 


IP fragment with negative fragmentation offset 


1 - ALERT 


Maximum fragments for a single IP packet reached 


1 - ALERT 


Session pool exhausted 


1 - ALERT 


TCP: Detected portscan. %IP_P2 


1 - ALERT 


TCP: Detected SYN Flood attack. %IP_P2 


1 - ALERT 


TCP: Duplicated session %IP_P2 


1 - ALERT 


TCP: External host already exists %IP_P2 


1 - ALERT 


TearDrop-like attack: invalid fragmentation offset value 


1 - ALERT 


UDP fragmentation attack: constructed payload larger than specified 
in UDP header 


1 - ALERT 


UDP fragmentation attack: constructed payload less than specified in 
the UDP header 


1 - ALERT 


UDP: Duplicated session %IP_P2 


2 - CRIT 


Init: Error reading ATE SR entries 


2 - CRIT 


Init: Error reading java filter 


2 - CRIT 


Init: Error reading selective IP ranges for ActiveX filtering 


2 - CRIT 


Init: Error reading selective IP ranges for Java filtering 


2 - CRIT 


Init: Error reading translation host entries 


2 - CRIT 


Init: Failed to allocate memory for %d IP ranges for ActiveX Filters 


2 - CRIT 


Init: Failed to allocate memory for %d IP ranges for Java Filters 


2 - CRIT 


Init: Failed to allocate memory for ATEs, entries: %d 


2 - CRIT 


Init: Failed to allocate memory for CLS Commands 


2 - CRIT 


Init: Failed to allocate memory for CLS commands 
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Table 19 Firewall and NAT Alarms 



Severity 


Report Text 


2 - CRIT 


Init: Failed to allocate memory for CLS Control module 


2 - CRIT 


Init: Failed to allocate memory for gating rules 


2 - CRIT 


Init: Failed to allocate memory for gating rules: %d 


2 - CRIT 


Init: Failed to allocate memory for host ranges: %d 


2 - CRIT 


Init: Failed to allocate memory for host table entries 


2 - CRIT 


Init: Failed to allocate memory for host table entries: %d 


2 - CRIT 


Init: Failed to allocate memory for secure host ranges: %d 


2 - CRIT 


Init: Failed to allocate memory for security classes 


2 - CRIT 


Init: Failed to allocate memory for security classes: %d 


2 - CRIT 


Init: Failed to allocate memory for service rules: %d 


2 - CRIT 


Init: Failed to allocate memory for service tuples 


3 - ERROR 


Deny: UDP under Flood attack %IP_P2 


3 - ERROR 


Authentication cache overflowed 


3 - ERROR 


Could not create timer event, error %d 


3 - ERROR 


Deny: ActiveX control %CMD, %IP2 


3 - ERROR 


Deny: Badly formed FTP PORT response, %IP_P2 


3 - ERROR 


Deny: GRE packet, %IP2 


3 - ERROR 


Deny: ICMP %IP2 


3 - ERROR 


Deny: ICMP fragmented packet %IP2_X 


3 - ERROR 


Deny: ICMP message too short, length %d, %IP_TC 


3 - ERROR 


Deny: ICMP packet with bad checksum, %IP_TC 


3 - ERROR 


Deny: ICMP Unsolicited ICMP reply packet. %IP2_ICMP 


3 - ERROR 


Deny: ICMP unsupported packet %IP2_ICMP 


3 - ERROR 


Deny: java applet %CMD, %IP_P2 
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Severity 


Report Text 


3 - ERROR 


Deny: No filter for %s, %IP_2 


3 - ERROR 


Deny: No filter for ICMP, %IP_2 


3 - ERROR 


Deny: no matching filter, %IP2_ICMP 


3 - ERROR 


Deny: OSPF packet, %IP2 


3 - ERROR 


Deny: TCP Christmas Tree Packet, %IP_P2 


3 - ERROR 


Deny: TCP SYN+ACK packet blocked. 


3 - ERROR 


Deny: TCP SYN+ACK packet without ever seeing SYN packet. 
%IP_P2 


3 - ERROR 


Deny: TCP ACK packet, session not open %IP_P2 


3 - ERROR 


Deny: TCP Con_Req %IP_P2 


3 - ERROR 


Deny: TCP Conn IP_P2 


3 - ERROR 


Deny: TCP IN Con_Req - SYN Flood attack %IP_P2 


3 - ERROR 


Deny: TCP Possible break-in attempt, %IP_P2 


3 - ERROR 


Deny: TCP Un-Auth host %IP_P2 


3 - ERROR 


Deny: TCP, no policy, %IP_P2 


3 - ERROR 


Deny: UDP %IP_P2 


3 - ERROR 


Deny: UDP, no policy applies, %IP_P2 


3 - ERROR 


Deny: UDP, no policy, %IP_P2 


3 - ERROR 


Failed to allocate memory for a reply packet 


3 - ERROR 


Failed to install protected mode timer tick handler 


3 - ERROR 


ICMP Flood attack detected %IP_P2 


3 - ERROR 


Index of an inactive timer entry passed to osUntimeOut() call 


3 - ERROR 


Init: Failed to allocate memory for TimerEntries 


3 - ERROR 


Init: Failed to allocate memory for user authentication 
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Severity 


Report Text 


3 - ERROR 


Internal error 


3 - ERROR 


IP fragment cache entry purged 


3 - ERROR 


IP header checksum does not match, %IP_P2 


3 - ERROR 


osllnTimeOutO called with a bad index = %d 


3 - ERROR 


Received fragmented Packet without the initial fragment 


3 - ERROR 


TCP header checksum does not match, %IP_P2 


3 - ERROR 


TCP: ACK packet in the TCP three-way handshake sequence was 
blocked. %s 


3 - ERROR 


TCP: Detected possible process table attack using sequence number 
guessing. %IP_P2 


3 - ERROR 


TCP: Maximum allowed inbound connections exceeded from host 
%IP_P2 


3 - ERROR 


TCP: Non-empty ACK packet in TCP three-way handshake sequence 
%IP_P2 


3 - ERROR 


TCP: RST packet indicating non-existing service was blocked %IP P2 


3 - ERROR 


UDP: Detected UDP Flood attack %IP_P2 


3 - ERROR 


UDP: Duplicated external host %IP_P2 


3 - ERROR 


UDP: Maximum allowed inbound connections exceeded from host 
%IP_P2 


3 - ERROR 


UDP: new session request %IP_P2 


3 - ERROR 


UDP: Request Entry pool is empty 


3 - ERROR 


Unsupported ICMP packet %IP2_ICMP 


4- WARNING 


%s session purged %IP_P2 


4 -WARNING 


Bad FTP Entry 


4- WARNING 


Badly formed FTP PORT command, %IP_P2 


4- WARNING 


Cannot schedule any more timer events 
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Table 19 Firewall and NAT Alarms 



Severity 


Report Text 


4- WARNING 


CLS blocked FTP request, command: %CMD %IP_P2 


4- WARNING 


CLS blocked HTTP request, command: %CMD %IP_P2 


4- WARNING 


CLS blocked HTTP stray packet, %IP_P2 


4- WARNING 


CLS blocked SMTP request, command: %CMD %IP_P2 


4- WARNING 


CLS blocked stray SMTP packet, %IP_P2 


4- WARNING 


Could not allocate TCP buffer for H.323 connection. %IP_P2 


4- WARNING 


Deny: User Authentication packet, %IP2 


4- WARNING 


FTP packet cannot be forwarded since no free NAT port available for 
FTP 


4- WARNING 


FTP Request pool is empty 


4- WARNING 


IP fragment cache table is empty 


4 -WARNING 


Log: TCP, Policy %POL, %IP_P2 


4- WARNING 


Log: UDP, Policy %POL, %IP_P2 


4 -WARNING 


Permit: ActiveX control %CMD, %IP_P2 


4 -WARNING 


Permit: Allow-log Filter %POL, %IP_P2 


4 -WARNING 


Permit: EGP packet, %IP2 


4- WARNING 


Permit: GRE packet, %IP2 


4- WARNING 


Permit: ICMP %IP2_ICMP 


4- WARNING 


Permit: IGMP packet, %IP2 


4- WARNING 


Permit: IGRP packet, %IP2 


4- WARNING 


Permit: java applet %CMD, %IP_P2 


4- WARNING 


Permit: OSPF packet, %IP2 


4 -WARNING 


Permit: TCP BGP packet, %IP2 


4 -WARNING 


Permit: TCP Con_Est, %IP_P2 
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Severity 


Report Text 


4- WARNING 


Permit: TCP Con_Req, %IP_P2 


4- WARNING 


Permit: UDP %IP_P2 


4- WARNING 


TCP connection closed %IP_P2 


4- WARNING 


TCP new session request %IP_P2 


4- WARNING 


TCP Out-Of-Sequence table is full 


4- WARNING 


UDP: Bad entry found in UDP Request cache table 


4- WARNING 


UDP: Bad response, %IP_P2 


4- WARNING 


UDP: Received Bad BOOTP Frame 


4- WARNING 


UDP: Unsolicited Req. (Resp expected), Ext->lnt: %IP2 


4- WARNING 


UDP: Unsolicited Resp. (Req expected), %\P2 


4- WARNING 


UDP: Unsolicited response, %IP_P2 


6- INFO 


ECHO request from %IP1 


6- INFO 


UDP: %d pending response, %IP_P2 
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